From 0c99ac3d7e5855b3a2623c6ca028b7f94672a692 Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Thu, 16 Jan 2020 17:40:44 -0600 Subject: [PATCH] Capture a backtrace before calling wasm (#830) * Capture a backtrace before calling wasm This helps mitigate the issue, at least locally, described in #829 and there's some more comments inline in the code as well. * Run rustfmt * Move around where the trace happens --- crates/runtime/src/signalhandlers.rs | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/crates/runtime/src/signalhandlers.rs b/crates/runtime/src/signalhandlers.rs index 5beb737769..97f27b9b42 100644 --- a/crates/runtime/src/signalhandlers.rs +++ b/crates/runtime/src/signalhandlers.rs @@ -61,6 +61,17 @@ pub extern "C" fn wasmtime_init_eager() { state.tried = true; assert!(!state.success); + // This is a really weird and unfortunate function call. For all the gory + // details see #829, but the tl;dr; is that in a trap handler we have 2 + // pages of stack space on Linux, and calling into libunwind which triggers + // the dynamic loader blows the stack. + // + // This is a dumb hack to work around this system-specific issue by + // capturing a backtrace once in the lifetime of a process to ensure that + // when we capture a backtrace in the trap handler all caches are primed, + // aka the dynamic loader has resolved all the relevant symbols. + drop(backtrace::Backtrace::new_unresolved()); + if unsafe { EnsureEagerSignalHandlers() == 0 } { return; }