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:
@@ -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);
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user