Re: [Boost-users] multi_index_container assertion after crash

Subject: Re: [Boost-users] multi_index_container assertion after crash
From: joaquin_at_[hidden]
Date: 2009-10-13 09:51:12

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