Dynamic linking suppresses stackeroverflow detection #110810
Comments
Eliah-Lakhin
added
C-bug
|
An easier way to reproduce: compile #[allow(unconditional_recursion)]
fn bar() {
bar()
}
#[no_mangle]
pub extern "C" fn foo() {
bar()
}with crate-type = ["cdylib"]and try to actually call this function: void foo(void);
int main(void) {
foo();
}It seems like dynamic linking suppresses stack overflow detection. I’m not sure that’s a bug. |
Noratrieb
added
T-libs
Noratrieb
changed the title
|
Changing the labels and title according to the investigation from @GoldsteinE |
|
@Nilstrieb hmm, did you mean to label this as T-libs? Anything to do with guard pages seems like it should be T-compiler to me. |
jyn514
added
A-linkage
|
Ah, is this actually missing guard pages? Fair then, I though it was hitting them and just missing the stackerflow detection, which is implemented in the library. |
|
I'll slap A-runtime on it to be safe 😄 |
rustbot
added
the
A-runtime
|
For dylibs we skip the runtime initialization of libstd, which is responsible for setting up the stack overflow handler (and adding a guard page on platforms that don't have this already. Linux and OpenBSD add one by default). Doing this in a global constructor would be bad as it could overwrite an existing SIGSEGV handler in case of dlopen. In this case however rustc actually overwrite the SIGSEGV handler of rustc's copy of libstd to show backtraces if LLVM crashes. It is this SIGSEGV handler that is shown here. If rustc didn't override the SIGSEGV handler, rustc's copy of libstd would have printed the stack overflow message. |
Code
The crate type is
[lib] proc_macro = true. There are no explicit dependencies.lib.rs code is:
Invoking the macro in another crate leads to the following
signal: 11, SIGSEGV: invalid memory referenceerror when compiling that other crate.Meta
Reproduced on Stable:
And nightly:
Error output
Backtrace
The text was updated successfully, but these errors were encountered: