Re: [Boost-users] multi_index_container assertion after crash

Subject: Re: [Boost-users] multi_index_container assertion after crash
From: Eli Zakashansky (Eli.Zakashansky_at_[hidden])
Date: 2009-10-14 04:31:08

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_at_[hidden] [mailto:boost-users-bounces_at_[hidden]] On Behalf Of joaquin_at_[hidden]
Sent: Tuesday, October 13, 2009 3:51 PM
To: boost-users_at_[hidden]
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_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users