worker: better error handling for memory maps

Previously, we would bail out of using memory maps if we could detect
ahead of time that opening a memory map would fail. The only case we
checked was whether the file size was 0 or not.

This is actually insufficient. The mmap call can return ENODEV errors
when a file doesn't support memory maps. This is the case for new files
exposed by Linux, for example,
/sys/devices/system/cpu/vulnerabilities/meltdown.

We fix this by checking the actual error codes returned by the mmap call.
If ENODEV (or EOVERFLOW) is returned, then we fall back to regular `read`
calls. If any other error occurs, we report it to the user.

Fixes #760
This commit is contained in:
Andrew Gallant
2018-01-31 19:20:36 -05:00
parent 0fedaa7d28
commit 93943793c3
2 changed files with 29 additions and 2 deletions

View File

@@ -9,6 +9,7 @@ extern crate grep;
extern crate ignore;
#[macro_use]
extern crate lazy_static;
extern crate libc;
#[macro_use]
extern crate log;
extern crate memchr;
@@ -339,7 +340,6 @@ fn eprint_nothing_searched() {
// https://github.com/BurntSushi/ripgrep/issues/200.
#[cfg(unix)]
fn reset_sigpipe() {
extern crate libc;
unsafe {
libc::signal(libc::SIGPIPE, libc::SIG_DFL);
}