sfackler / jemalloc-ctl

Apache License 2.0
9 stars 3 forks source link

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" } #6

Open wilg opened 5 years ago

wilg commented 5 years ago

Basic usage seems to crash my program. I'm only a few months in to Rust, so perhaps I'm doing something incredibly wrong here, but this has me baffled.

#[global_allocator]
static ALLOC: jemallocator::Jemalloc = jemallocator::Jemalloc;

fn main() {
    println!(
        "background_thread: {}",
        jemalloc_ctl::background_thread().unwrap()
    );
    // rest of my program
}

The same thing happens if I try to get or set the number of background threads.

Here's the error:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/libcore/result.rs:1009:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:211
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:227
   4: <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
             at src/libstd/panicking.rs:491
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:398
   6: std::panicking::try::do_call
             at src/libstd/panicking.rs:325
   7: core::char::methods::<impl char>::escape_debug
             at src/libcore/panicking.rs:95
   8: <std::sys::unix::time::inner::Instant as core::cmp::PartialOrd>::partial_cmp
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libcore/macros.rs:26
   9: <core::result::Result<T, E>>::unwrap
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libcore/result.rs:808
  10: world_server::main
             at src/main.rs:36
  11: std::rt::lang_start::{{closure}}
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libstd/rt.rs:74
  12: std::panicking::try::do_call
             at src/libstd/rt.rs:59
             at src/libstd/panicking.rs:310
  13: panic_unwind::dwarf::eh::read_encoded_pointer
             at src/libpanic_unwind/lib.rs:102
  14: <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
             at src/libstd/panicking.rs:289
             at src/libstd/panic.rs:398
             at src/libstd/rt.rs:58
  15: std::rt::lang_start
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libstd/rt.rs:74
  16: world_server::main

Also, do you happen to know if jemalloc's background threads are enabled by default or not?

sfackler commented 5 years ago

That control in particular only works if background threads were compiled into jemalloc. I know that they're not supported on macOS, for example.

wilg commented 5 years ago

Ah, shoot, that must be it, I'm using macOS for development. Any advice for the best way to detect if its supported? I'd like to have my program work on macOS but have the background thread enabled on Linux (which is the production environment).

Also, are there any alternatives to this background thread that you can think of? I've got a program that typically uses very little memory but occasionally has large spikes for a particular task. I'd like to return that memory to the OS (which Rust doesn't seem to do by default) since it is running in a web server environment and the platform will kill the process if it stays above its memory budget for too long.

sfackler commented 5 years ago

I just try to enable background threads and log a warning if that fails personally.