Re: [Boost-users] multi_index_container assertion after crash

Subject: Re: [Boost-users] multi_index_container assertion after crash
From: Andrew Holden (aholden_at_[hidden])
Date: 2009-10-20 12:40:40

joaquin_at_[hidden] wrote on Monday, October 19, 2009 10:40 AM:
>
> I'm afraid I can't be of more help with the information you've got.
From
> your description of the problem, the container can't possibily be
corrupted
> because you know that crashes never happen in the middle of an
> op container. Also, iterators are not persisted and they seemingly
work
> OK except when recovering after a crash. I don't see where the
> problem might be, though a problem certainly is there.

I haven't been following this thread too closely, so forgive me if this
is off target.

Is it possible that, when your process crashes, the operating system
doesn't bother to properly flush the mapped file to disk?  I have read
that some versions of UNIX will produce undefined results if you don't
sync a mapped file before closing it, even in an orderly shutdown.  I
think Windows is better about that, but I don't know what happens in a
crash.

What operating system are you using? (An earlier reference to "task
manager" implies Windows.) Does anybody know if boost::interprocess
needs to do anything special to flush mapped files in that platform?  If
so, the operating system won't permit it to do so in a crash.  Even if
interprocess doesn't need to do anything, it's still possible that the
operating system might decide to discard anything that wasn't already
flushed for some reason.