[Boost-users] Re: MultiIndexSet invariant test failure

From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2005-04-13 13:46:30

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

> 
> > Date: Wed, 13 Apr 2005 06:58:01 +0000 (UTC)
> > From: Joaquin M Lopez Munoz <joaquin <at> tid.es>
> > Subject: [Boost-users] Re: MultiIndexSet invariant test failure
> > To: boost-users <at> lists.boost.org
> > Message-ID: <loom.20050413T084751-297 <at> post.gmane.org>
> > Content-Type: text/plain; charset=utf-8
> >
> > So, once you have mutex-guarded your code, the problem
> > does not show? Please confirm.
> The invariant test fails (asserts) on a call to 'insert()' regardless of
> my mutex
> gaurds. I have even gone as far as to wrap 'read' methods such as calls
> to 'size()'
> and 'empty()' with mutexes.

OK, this is a different story.

> 
> > Other than that, you'll have to guard your code with
> > mutexes like you say you're doing now.
> Yes, I understand this, but it seems that the invariant assertion is
> happening
> and it may not (?) necessarily be related to a threading issue.
> According to my
> backtrace, it appears that I do not have a thread contention issue.
> There is only one thread that is performing a call to any of the
> container methods 
> (the other threads are waiting on a mutex release), and that call is
> 'insert()',
>  and it is causing the aforementioned invariant assert.
> 
> The invariant assert does not happen during every test run, but it does
> happen frequently.
> What are the kinds of things that could cause the invariant assert?  The
> documentation
> doesn't go into any great detail in this area.

The following possibilities exist:

1. A bug in my library.
2. The comparison predicate you're passing is not correct
(i.e. it does not implement a strict weak ordering.)
3. Elements are dynamic (pointers to objects) and you did
a premature delete on one or some of them.
4. The multi_index_container you call insert() upon has
been deleted, overwritten, etc.
5. You're running out of memory and new() does not throw
bad_alloc (this can happen in MSVC++ 6.5 and, maybe, 7.0.)
6. You haven't selected a multithreaded version of
the runtime library.
7. You guarded write access to an index but *not* to
other indices of the same container.
8. You modified some elements (vg. via const_cast) and
violated the invariants of the container.
9. ...

Questions:

1. I'd like to analyze this. I can run tests in GCC/Cygwin.
Could your test be run on this platform? If not, could you
at least disclose the code so that I can take a look at it?
2. Does your debugging environment allow you to peek
at the variables when the assert happens?

> 
> > Hope this helps. Best regards,
> Any help is most welcome; thanks!

Thank *you* for reporting the problem.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo