Re: [Boost-users] [multi_index] Problem of scope with the replace in static data structure

Subject: Re: [Boost-users] [multi_index] Problem of scope with the replace in static data structure
From: joaquin_at_[hidden]
Date: 2009-02-11 12:27:37

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