4 ms·

Claiming Bitcoin's Bug Bounty

74 points by hendzen 13y ago

Aqueous 13y ago
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 13y ago
  I assume he meant one of the log/database files that contains the corruption.
  - Aqueous 13y ago
    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 13y ago
      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 13y ago
        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 13y ago
  Gavin posted a link to some corrupt LevelDB instances here: https://github.com/bitcoin/bitcoin/issues/2770 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 13y ago
[deleted]
- rescrv 13y ago
  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 13y ago
    [deleted]
    - rescrv 13y ago
      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 13y ago
      [deleted]
  - nl 13y ago
    Man, it's annoying when someone deletes comments, especially right through a thread!
- agwa 13y ago
  > 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 13y ago
The Darwin man page for munmap has more detail: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/munmap.2.html#//apple_ref/doc/man/2/munmap 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&i=munmap http://fxr.watson.org/fxr/ident?v=xnu-2050.18.24&im=excerpts...
- kristianp 13y ago
  Does this mean it's a bug in Darwin?
moneyrich4 13y ago
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 )

74 points by hendzen 13y ago

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 13y ago
I assume he meant one of the log/database files that contains the corruption.
- Aqueous 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
Gavin posted a link to some corrupt LevelDB instances here: https://github.com/bitcoin/bitcoin/issues/2770 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 13y ago

[deleted]

rescrv 13y ago
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 13y ago
  [deleted]
  - rescrv 13y ago
    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 13y ago
    [deleted]
- nl 13y ago
  Man, it's annoying when someone deletes comments, especially right through a thread!
agwa 13y ago
> 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 13y ago

The Darwin man page for munmap has more detail: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/munmap.2.html#//apple_ref/doc/man/2/munmap 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&i=munmap http://fxr.watson.org/fxr/ident?v=xnu-2050.18.24&im=excerpts...

kristianp 13y ago
Does this mean it's a bug in Darwin?

moneyrich4 13y ago

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 )