Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Out-of-stack failure leaks arguments #3555

Closed
brson opened this issue Sep 22, 2012 · 5 comments
Closed

Out-of-stack failure leaks arguments #3555

brson opened this issue Sep 22, 2012 · 5 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows

Comments

@brson
Copy link
Contributor

brson commented Sep 22, 2012

This is a major bummer.

// error-pattern:ran out of stack
fn main() {
    eat(move ~0);
}

fn eat(
    +a: ~int
) {
    eat(move a)
}
rust: task 66d35f0 ran out of stack
rust: domain main @0x66d1f40 root task failed
leaked memory in rust main loop (1 objects)
out-of-stack-owned-box.stage1-x86_64-unknown-linux-gnu: /home/brian/dev/rust/src/rt/memory_region.cpp:172: memory_region::~memory_region(): Assertion `false' failed.
==26532== 40 bytes in 1 blocks are definitely lost in loss record 2 of 5
==26532==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26532==    by 0x52A8B08: memory_region::malloc(unsigned long, char const*, bool) (memory_region.cpp:110)
==26532==    by 0x5290B51: upcall_s_exchange_malloc (rust_upcall.cpp:153)
==26532==    by 0x52A944C: ??? (in /home/brian/dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/x86_64-unknown-linux-gnu/lib/librustrt.so)
==26532== 
@brson
Copy link
Contributor Author

brson commented Sep 22, 2012

I added tests in run-fail/out-of-stack-managed-box.rs and out-of-stack-owned-box.rs. The managed box test succeeds unexpectedly, probably because the annihilator takes care of it.

@brson
Copy link
Contributor Author

brson commented Sep 22, 2012

The reason this happens is because we throw an exception in the middle of retrieving a stack, and I assume no stack frame exists that claims ownership of the arguments.

@brson brson mentioned this issue Jan 4, 2013
brson added a commit to brson/rust that referenced this issue Apr 26, 2013
People hit the recursion depth limit too often, it's not possible
to unwind reliably from out-of-stack.

Issues rust-lang#3555, rust-lang#3695
bors added a commit that referenced this issue Apr 27, 2013
People hit the recursion depth limit too often, it's not possible
to unwind reliably from out-of-stack.

Issues #3555, #3695
@emberian
Copy link
Member

emberian commented Jul 7, 2013

@brson is this still relevant?

@catamorphism
Copy link
Contributor

This test case segfaults now, so I can't tell if it leaks arguments. Nominating for milestone 5, production-ready. (Oops, it's already on that milestone.)

@thestinger
Copy link
Contributor

Out-of-stack now simply aborts. It could be taught to unwind, but it would cause undefined behaviour without teaching LLVM that all functions can unwind. That's likely what was happening here.

bors pushed a commit to rust-lang-ci/rust that referenced this issue May 15, 2021
fix `Const generics are handled incorrectly`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows
Projects
None yet
Development

No branches or pull requests

4 participants