Claiming Bitcoin's Bug Bounty
hackingdistributed.com
hackingdistributed.com
Deleted comment
Changes to private mappings aren't supposed to be reflected in the underlying file, so this statement is a bit of a truism.
Changes to shared mappings, on the other hand, are supposed to be reflected in the file, and that's what this article is about.
Additionally, the statement you quote explicitly relates to private mappings. LevelDB uses shared mappings.
Deleted comment
Your random quotes from man pages are out of context (and keep changing as you edit your posts).
If the mapping maps data from a file (MAP_SHARED), then the memory will eventually be written back to disk if it's dirty. This will happen automatically at some point in the future (implementation dependent).
The XNU source may be useful: http://fxr.watson.org/fxr/ident?v=xnu-2050.18.24&im=excerpts...I took a look at them, and figured out what in the write path could have gone wrong to create the bad behavior. It turned out to be in db/log_writer.cc and deps.
I cannot promise there are no other bugs within Bitcoin or LevelDB, but this resolves one issue. I'm interested in seeing it tested in the wide area, just to make sure.
Of course, if there are other bugs, I'm just as happy to debug and squash them.