joaquin@tid.es 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.