"fatal, 'on_rust_stack()' failed" with recursive resource

[jruderman]

resource r(b: int) { r(b); }
fn main() { r(0); }

Hits a fatal assertion rather than simply failing:

rust: task 7fce71800000 ran out of stack
rust: fatal, 'on_rust_stack()' failed, ../src/rt/rust_task.cpp:570 

[brson]

I don't see that assert fail, instead this:

rust: task 6598840 ran out of stack
terminate called after throwing an instance of 'rust_task*'
==14512== 136 bytes in 1 blocks are possibly lost in loss record 10 of 23
==14512==    at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
==14512==    by 0x633E232: __cxa_allocate_exception (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.14)
==14512==    by 0x5472688: rust_task::fail() (rust_task.cpp:256)
==14512==    by 0x5472CAC: rust_task::new_stack(unsigned long) (rust_task.cpp:504)
==14512==    by 0x5485CB8: ??? (in /home/banderson/Dev/rust2/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/x86_64-unknown-linux-gnu/lib/librustrt.so)
==14512== 

Which is also bad

[brson]

This may be a symptom of the general brokenness of failing destructors (#910)

[catamorphism]

Translating this test to use structs, I correctly got the "ran out of stack" error. There are no errors with valgrind. Added the test, closing this.

[brson]

The mac bots are failing this test: http://bot.rust-lang.org/logs/2012/10/02/2012-11-02T00:07:27Z-24734e01-de89-40ba-b676-f7205dd22bd2.html

I xfailed it.

[catamorphism]

The test fails on the Mac bot because the test executable is returning an exit code of 1 instead of 101. @brson advised that the bot behavior is likely because the unwinder doesn't know what to do and calls abort() (whereas unwinding seems to work correctly because of my machine). He thought maybe the difference was due to optimization, so I'll try recompiling on my machine with optimization enabled.

[catamorphism]

I confirmed that the test fails with optimization enabled, but passes with optimization disabled. In the optimized version, in rust_task::task_start_wrapper, the catch block appears never to execute, which means the cleanup code doesn't run and the code that would return the correct exit code isn't reached. In the unoptimized version, the catch block does execute. That's about as much as I could figure out.

[brson]

As part of #3695 I want to make running out of stack a fatal runtime error, instead of a recoverable task failure, so hopefully that will make this issue moot.

[pnkfelix]

visited for triage. I think at this point this should probably be treated as a duplicate of #3695, in the sense that whatever resolution we end up with for that bug should also dictate the resolution for this bug.

[catamorphism]

#910 is milestoned for 1.0, so this one is low priority on its own.

[alexcrichton]

Closing in favor of #11011, I'm not entirely certain what a resource is, but we don't have stack switching any more, we do have prints on stack overflow, and #11011 should cover using fail!() instead of abort