Joaquín hi, I understand perfectly what u tried to do (and also experienced such problems before), therefore I verified that after I obtain the index(idx = container->get<INDEX>();) it is not changes (only read methods such as end(), begin() etc. are invoked) until I try to remove an element from the container (idx.erase(iterator);), and on the first try I try to call erase the assertion pops up. Thanks again for you response, Eli. -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of joaquin@tid.es Sent: Wednesday, October 14, 2009 12:48 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] multi_index_container assertion after crash Eli Zakashansky escribió:
Joaquín hi,
First thanks for your response.
The iterators I use are not persistent (I am retrieving the iterators from the index each time I am adding or removing element to/from the container). And even though the crash happens during massive use of the container, it does not happens in the middle of multi_index_container op (I have an applications log where I can see when exactly where in the code the app. crashes). I thought that may be the multi_index_container shall be flushed to the disk (it will effect performance) but I didnt find any method to do it.
For more information I would like to tell you in general about the test I do: 1. at first I populate my multi_index_container with elements (~4000). 2. I invoke a process which removes elements from the container (and processing each element after its removal - this phase doesn't relate to any boost structure ). During stage # 2 I am killing the process via task manager.
Umm, maybe we're looking at the wrong area and this has nothing to do with persistence. Consider the following piece of pseudocode: multi_index_container<...> m; auto it=m.find(...); m.erase(it); auto it2=it1; // WRONG See the last line? Once you've deleted the element a given iterator points at, this iterator becomes invalid and the only thing you can do with it is assign it a new value --you can't copy it, use it as the right part of an assignment, etc. If safe mode is on, assertions like the one you're seeing will pop up. Maybe you're having such a problem in your code? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users