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

1 files changed, 1 insertions, 1 deletions

diff --git a/src/main.rs b/src/main.rs
index f7407eab..7d39aa66 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -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);
     }