Hello, I just accidentally wrote an infinite recursive function (not a tail call). Usually, this results in getting this message:
thread '' has overflowed its stack
fatal runtime error: stack overflow
But in my program, I get a segmentation fault:
When I start it using cargo test volkertest, I get:
process didn't exit successfully: `/path/to/binary volkertest` (signal: 11, SIGSEGV: invalid memory reference
And when I run it in the vscode debugger, I get
Stop reason: signal SIGSEGV: address access protected (fault address: 0x7ffff7a29ff8)
The call stack is:
len<core::option::Option<bindgen::ir::item::Item>> (/home/volker/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:95)
get<core::option::Option<bindgen::ir::item::Item>> (/home/volker/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/index.rs:155)
get<core::option::Option<bindgen::ir::item::Item>,usize> (/home/volker/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:282)
resolve_item_fallible<bindgen::ir::context::ItemId> (/home/volker/Sync/git/rust-bindgen/src/ir/context.rs:1475)
resolve_item<bindgen::ir::context::ItemId> (/home/volker/Sync/git/rust-bindgen/src/ir/context.rs:1483)
resolve (/home/volker/Sync/git/rust-bindgen/src/ir/context.rs:2700)
is_constified_enum_module (/home/volker/Sync/git/rust-bindgen/src/ir/item.rs:964)
is_constified_enum_module (/home/volker/Sync/git/rust-bindgen/src/ir/item.rs:982)
is_constified_enum_module (/home/volker/Sync/git/rust-bindgen/src/ir/item.rs:982)
...
is_constified_enum_module (/home/volker/Sync/git/rust-bindgen/src/ir/item.rs:982)
is_constified_enum_module (/home/volker/Sync/git/rust-bindgen/src/ir/item.rs:982)
...
start_thread (@start_thread:51)
Here, someone said that:
which sounds like rust is guaranteed to print "has overflowed its stack" instead of "signal SIGSEGV", which would mean that we have a bug here. Anyone knows if that is true? Is rust GUARANTEED to ALWAYS print "has overflowed its stack" instead of segfaulting? If yes, we just found a bug.