Crashes on Snappy decompression (mmap/MapViewOfFile issues?)
- Dominant language
- C++
- Stars
- 39.4k
- Forks
- 8.2k
- PR merge metrics
- No merged PRs in 30d
Description
I'm seeing crashes during Snappy decompression that I suspect are due to disk failures triggered by memory mapped file reads.
```
[ 00 ] snappy::SnappyDecompressor::DecompressAllTags
[ 01 ] snappy::RawUncompress
[ 02 ] leveldb::ReadBlock
[ 03 ] leveldb::Table::BlockReader
[ 04 ] leveldb::`anonymous namespace'::TwoLevelIterator::InitDataBlock
[ 05 ] leveldb::`anonymous namespace'::TwoLevelIterator::Seek
[ 06 ] leveldb::`anonymous namespace'::MergingIterator::Seek
[ 07 ] leveldb::`anonymous namespace'::DBIter::Seek
```
A similar issue has been reported a long time ago https://github.com/google/leveldb/issues/221, but it was closed without a definitive solution. The issue is not on `snappy` -- as mentioned in #221. That code is thoroughly exercised in Chromium.
But the File implementation used by `env_chromium.cc` doesn't rely on memory mapping -- https://cs.chromium.org/chromium/src/base/files/file_win.cc?sq=package:chromium&g=0&l=77 -- so I suspect these crashes are related to the native LevelDB `Env` implementations using `mmap` on POSIX and `MapViewOfFile` on Windows.
Is it possible to configure LevelDB to not use memory mapping? That would allow me to investigate further. Would a PR adding this be welcome? Should this be a compile-time flag or a runtime option passed to `Env::Default()`?
Contributor guide
Assessment
This issue has not been assessed yet.