
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 didn't 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. Thanks a lot! Eli. -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of joaquin@tid.es Sent: Tuesday, October 13, 2009 3:51 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] multi_index_container assertion after crash Eli Zakashansky escribió:
Hi,
I have an application which uses a persistent multi_index_container (I am using bip::managed_mapped_file && after openning the file I do "container = mappedFile->find_or_construct(.)"). I have an interesting behavior when my process crashes/stopped during massive use of the multi_index_container after the process restarts I don't experience any problems reading or inserting new elements to the container but if I try to erase elements or call mutli_index_container::clear (Debug mode only BOOST_MULTI_INDEX_ENABLE_SAFE_MODE is defined) an assertion pops up (safe_mode::Check_same_owner / safe_mode::Check_valid_iterator).
At first I thought that this kind of assertion fails due to concurrency issue, but it is not the case (I verified that this data structure is not accessed from more than one thread at a time, during this time the container is locked). Does anyone has any idea what can cause this situation? Or has a resolution ?
Hi Eli, I'm afraid you're providing too little information, but let me try a shot in the dark: are you persisting multi_index_containers iterators as well? These iterators are *not* persistable in managed memory as they contain absolute pointers as their representation. Can this be related to the problem? Other than this, I sincerely don't have a clue. If the crash/stop happens in the middle of a multi_index_container op then the data structure can be left in an unconsistent state, though I'm having a hard time figuring out how this inconsistent state can result in safe mode assertions as the ones you describe. Maybe if you could provide a little more context I'd be able to be more helpful than this. 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