::rt::backtrace Backtraces are not very useful on Mac

[catamorphism]

If I do export RUST_LOG=rt.backtrace and then compile and run the following program:

fn z() { fail "fleh"; }

fn y() { z(); }

fn x() { y(); }

fn main() {
  x();
}

I would expect to see a backtrace that mentions the functions main, x, y, and z. Instead, I get:

rust: upcall fail 'fleh', ./src/test/run-fail/bt-test.rs:1
0   librustrt.dylib                     0x0000000102511279 __morestack + 9

I've seen similar results when running other programs. The stack trace says something about __morestack but nothing about function calls corresponding to the code the user wrote.

[brson]

I think we can probably write our own backtrace function with libunwind.

[jesse99]

With a unit test I wasn't getting any frames at all with Mac OS 10.7.2 and rust 0.2. I'd really like them so I spent some time digging around and got it working until it hit the infamous __morestack function where it went into lala land. Here is what I did:

1. In Makefile.in added -fno-omit-frame-pointer to CFG_GCCISH_CFLAGS when CFG_DISABLE_OPTIMIZE was set.
2. In rust_task::backtrace use a custom ::backtrace that allows for stack frames to be more highly aligned than _thread_stack_pcs expects and allows for stack frames to appear outside of where pthreads expects the stack to be.

With that fail was giving me stuff that looked like:
rust: upcall fail 'Assertion -1 == chopper(3, []) failed', katas/kata2.rs:21
0 librustrt.dylib 0x00000001045b7592 _ZN9rust_task4failEv + 144
1 librustrt.dylib 0x00000001045bbf8e upcall_s_fail + 286
2 librustrt.dylib 0x00000001045e79f8 __morestack + 9

Here are some links to the backtrace Darwin code I modified:
http://www.opensource.apple.com/source/Libc/Libc-498.1.1/gen/backtrace.c
http://www.opensource.apple.com/source/Libc/Libc-763.12/gen/thread_stack_pcs.c

[jesse99]

I did try running with gdb. When I used catch throw I was able to get a useful backtrace.

[Dretch]

Backtraces are not useful on linux either:

export RUST_LOG=::rt::backtrace
rustc -g fleh.rs && ./fleh

produces:

/home/gareth/projects/tests/../../../../usr/local/lib/rustc/x86_64-unknown-linux-gnu/lib/librustrt.so(_ZN9rust_task4failEv+0x28)[0x7f337a647bd8]
/home/gareth/projects/tests/../../../../usr/local/lib/rustc/x86_64-unknown-linux-gnu/lib/librustrt.so(+0x2d4c9)[0x7f337a65c4c9]
/home/gareth/projects/tests/../../../../usr/local/lib/rustc/x86_64-unknown-linux-gnu/lib/librustrt.so(upcall_fail+0x161)[0x7f337a64abc1]
./fleh[0x400af5]
./fleh[0x400bd2]
./fleh[0x400c12]
./fleh[0x400c52]
./fleh(_rust_main+0x4a)[0x400caa]
/home/gareth/projects/tests/../../../../usr/local/lib/rustc/x86_64-unknown-linux-gnu/lib/librustrt.so(_Z18task_start_wrapperP10spawn_args+0x2b)[0x7f337a6484eb]
rust: domain main @0x177abb0 root task failed

It would be useful if they included function paths and line numbers for each frame.

[catamorphism]

@Dretch can you get a good backtrace in gdb? (The RTS should still be able to print out a backtrace on its own, but gdb can be an ok stopgap for now.)

[Dretch]

@catamorphism running gdb --ex "catch throw" --ex run fleh gives a much more useful stacktrace:

Catchpoint 1 (exception thrown), 0x00007ffff66a0ff0 in __cxa_throw ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0x00007ffff66a0ff0 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007ffff754e35d in rust_task::fail (this=0x60a120)
    at /home/gareth/projects/rust/src/rt/rust_task.cpp:269
#2  0x00007ffff7563d79 in __morestack ()
   from /home/gareth/projects/tests/../../../../usr/local/lib/rustc/x86_64-unknown-linux-gnu/lib/librustrt.so
#3  0x00007ffff7551321 in call_on_c_stack (fn_ptr=0x7ffff75506a0, args=0x60af60, this=0x60a120)
    at /home/gareth/projects/rust/src/rt/rust_task.h:352
#4  call_upcall_on_c_stack (fn_ptr=0x7ffff75506a0, args=0x60af60)
    at /home/gareth/projects/rust/src/rt/rust_upcall.cpp:50
#5  upcall_fail (expr=<optimized out>, file=<optimized out>, line=<optimized out>)
    at /home/gareth/projects/rust/src/rt/rust_upcall.cpp:129
#6  0x0000000000400af7 in z () at fleh.rs:1
#7  0x0000000000400bd6 in y () at fleh.rs:3
#8  0x0000000000400c16 in x () at fleh.rs:5
#9  0x0000000000400c56 in main () at fleh.rs:8
#10 0x0000000000400cac in _rust_main ()
#11 0x00007ffff754ec4b in task_start_wrapper (a=<optimized out>)
    at /home/gareth/projects/rust/src/rt/rust_task.cpp:141
#12 0x0000000000000000 in ?? ()

[catamorphism]

Backtraces look better to me now, but we should have some sort of testing for this. Nominating for milestone 3, feature-complete

[jbclements]

#6823 is definitely related to this

[graydon]

accepted for production-ready milestone

[pnkfelix]

Visiting for triage, email from 2013-09-02.

So AFAICT, backtraces work better now under gdb on Mac OS X, but we have not closed this issue yet because there is no RUST_LOG=::rt::backtrace support there yet. I will change the title of this ticket accordingly.

[alexcrichton]

I believe this was removed actually. According to 494da5a this no longer exists (I think that changed with the new runtime).

[jbclements]

for posterity: the "right" way to do this now is just to use GDB, afaict.