RE: Re: MultiIndexSet invariant test failure
Date: Wed, 13 Apr 2005 06:58:01 +0000 (UTC) From: Joaquin M Lopez Munoz
Subject: [Boost-users] Re: MultiIndexSet invariant test failure To: boost-users@lists.boost.org Message-ID: 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.
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.
Hope this helps. Best regards, Any help is most welcome; thanks!
Manges, Ross G
Date: Wed, 13 Apr 2005 06:58:01 +0000 (UTC) From: Joaquin M Lopez Munoz
Subject: [Boost-users] Re: MultiIndexSet invariant test failure To: boost-users <at> lists.boost.org Message-ID: 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
participants (2)
-
Joaquin M Lopez Munoz
-
Manges, Ross G