Rodrigo Dias Ferreira escribió:
Hi Joaquim,
Can you please test the following? In your //Test of the commit section, rather than reuse graph_h please use a different variable to do the after-commitChanges check:
[...]
Does this make any difference?
Yes, it worked, if I instantiate another object (like graph_h2). After that I have done some more Debug to try to find the reason, but I still don't understand, because inside the constructor it finds the Nodes, when I use the same object (graph_h)... Inside the overloaded operator-> does not work anymore, even I am using the _localGraph in both stretch of codes. So if it was the assignment of the _localGraph, it should not work with the constructor also, isn't true?
What happens when you do *not* use graph_h2 is that, upon reassigning graph_h in graph_h = Graph_h(it); the previous value of graph_h is destroyed, and presumably this leaves some dangling pointer/iterator when it shouldn't. I've examined your code in search for candidates to potential dangling pointers/iterators and found something a little suspicious: Graph contains the following two member variables: uniqueNameTable _nodeNameRep; nodeIndex _nodeRep; where uniqueNameTable is a container of uniqueNodeNameStruct's and nodeIndex is a container of nodeMaps pointing to uniqueNodeNameStruct's in _nodeRep, right? If so, default copy semantics of Graph is flawed; consider: Graph g2; { Graph g1; // g1._nodeRep elements point into g1._nodeNameRep g2=g1; // g2._nodeRep elements point into g1._nodeNameRep } // g1 is destroyed // g2._nodeRep elements point to destroyed objects See what I mean? Pointers inside _nodeRep are not reassigned on copy. Does the copy constructor of Graph take this issue into account? If this leads nowhere, you can always try setting up Boost.MultiIndex safe mode: http://boost.org/libs/multi_index/doc/tutorial/debug.html#safe_mode and see if some safe mode assertion is triggered. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo