Manges, Ross G <Ross.G.Manges <at> boeing.com> writes:

Joaquin M Lopez Munoz wrote:

...

You've got to implement semantics equivalent to that of the < relationship between numbers: Thanks for the info; I now believe I'm doing this correctly.

...

* Now, in the piece of your code where the insert asserts, add a precheck of the invariant:

m.check_invariant_(); // point A m.insert(...); // point B

* Run your test till the assert fires. Is it in point A or B? If A, then most likely you're somehow modifying the elements in some other thread. Get the idea? This is a great idea! I added the precheck as you suggested, and it appears that I am experiencing the assert in 'point B'. The invariant is OK until the insertion breaks it. So can I infer that somehow what I'm inserting is invalid? It's a shared_ptr.

Two (main) possibilities: the shared_ptr is invalid or my code has a bug. Could you test the pointer for validity before making the insertion? m.check_invariant_(); // check ptr before insertion m.insert(ptr); If still the error is detected inside insert(), we can try to produce some sort of poorman dump of the container: define BOOST_MULTI_INDEX_INVARIANT_ASSERT to throw an exception on failure and wrap the call to insert() as follows: try{ m.insert(...); } catch(/* exception thrown by the assert */){ // dump the contents of m } Can you do that? Notice something weird in the dump? Can you post the dump?

I recently sent in another post regarding problems I'm having with shared_ptrs that might be related (see post w/subject: "shared_ptr use_count in multi threaded environment").

Maybe. But it could be a bug in Boost.MultiIndex, also. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo