HN Explorer

16 comments

[ 578 ms ] story [ 2951 ms ] thread
Aqueous
Has it been verified that the bug is fixed as in no further database corruption? I'm confused what you mean by this "sample" you got from Gavin.
MBCook
I assume he meant one of the log/database files that contains the corruption.
Aqueous
That's what I initially thought, but then I missed the part where they've confirmed that this fixes the bug. Has this been tested?
asdfaoeu
People were reporting it only happens on some installs and takes up to five days to present itself. Considering that this was only released today it seems too premature to confirm that.
Aqueous
Whenever I fix a bug I wait for confirmation that the bug has actually been fixed before I submit the patch. Sometimes, especially when fixing race conditions that occur unpredictably, it takes a while to confirm that the bug has been fixed. Not that I'm skeptical - it seems like they're pretty confident that they've fixed it.
rescrv
Gavin posted a link to some corrupt LevelDB instances here: https://github.com/bitcoin/bitcoin/issues/2770 He also sent the same link to me via email.

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.

[deleted]
(comment deleted)
rescrv
Can you link to the man page you are reading, because this is not in the Debian page for mmap(2), which includes munmap.

Additionally, the statement you quote explicitly relates to private mappings. LevelDB uses shared mappings.

[deleted]
(comment deleted)
rescrv
It uses shared writable mappings to reflect writes in the file on disk, and the core purpose of msync is to synchronize the file with the memory map.

Your random quotes from man pages are out of context (and keep changing as you edit your posts).

[deleted]
(comment deleted)
nl
Man, it's annoying when someone deletes comments, especially right through a thread!
agwa
> If a mapping to be removed was private, any modifications made in this address range shall be discarded.

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.

ers35
The Darwin man page for munmap has more detail: https://developer.apple.com/library/mac/documentation/Darwin... See DIRTY PAGE HANDLING.

  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...
kristianp
Does this mean it's a bug in Darwin?
[dead] moneyrich4
question: as a developer (10 yrs of c/php) how can i learn to avoid stuff like this?

would really love a good talk or screencast that explains some of this stuff - anyone got one?

( i know its kind of sad i dont know this alread - its why im not a kernel dev tho :P )