GDB should break on panic

[andrewrk]

Expected behavior:

• when I use gdb, gdb should catch the panic and I should be able to use bt to analyze the stack.
• when I use RUST_BACKTRACE=1 I should see source files and line numbers in the backtrace.

Actual behavior:

andy@andy-bx:~/dev/hackerrank/angry-children$ rustc --version
rustc 1.0.0-nightly (3d0d9bb6f 2015-01-12 22:56:20 +0000)
andy@andy-bx:~/dev/hackerrank/angry-children$ uname -a
Linux andy-bx 3.16.0-25-generic #33-Ubuntu SMP Tue Nov 4 12:06:54 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
andy@andy-bx:~/dev/hackerrank/angry-children$ rustc -g main.rs
main.rs:20:17: 20:18 warning: unused variable: `e`, #[warn(unused_variables)] on by default
main.rs:20             Err(e) => break
                           ^
main.rs:9:5: 9:23 warning: unused result which must be used, #[warn(unused_must_use)] on by default
main.rs:9     stdin.read_line();
              ^~~~~~~~~~~~~~~~~~
andy@andy-bx:~/dev/hackerrank/angry-children$ gdb ./main -ex run
GNU gdb (Ubuntu 7.8-1ubuntu4) 7.8.0.20141001-cvs
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...done.
warning: Missing auto-load scripts referenced in section .debug_gdb_scripts
of file /home/andy/dev/hackerrank/angry-children/main
Use `info auto-load python-scripts [REGEXP]' to list them.
Starting program: /home/andy/dev/hackerrank/angry-children/main 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
7
3
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/option.rs:362
[Inferior 1 (process 32760) exited with code 0145]
(gdb) bt
No stack.
(gdb) quit
andy@andy-bx:~/dev/hackerrank/angry-children$ RUST_BACKTRACE=1 ./main 
7
3
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/option.rs:362
stack backtrace:
   1:     0x7ff274f5f430 - sys::backtrace::write::hb7fa0f4f6b33ee3a8Rt
   2:     0x7ff274f62930 - failure::on_fail::h4388493538a5ad8ck8z
   3:     0x7ff274f566a0 - rt::unwind::begin_unwind_inner::h644ddf1c409df284cNz
   4:     0x7ff274f571d0 - rt::unwind::begin_unwind_fmt::h872fa98dc2f66468JLz
   5:     0x7ff274f62850 - rust_begin_unwind
   6:     0x7ff274f8e4b0 - panicking::panic_fmt::h4359f3a82e34f47bvym
   7:     0x7ff274f8e3c0 - panicking::panic::hcce94ca6d802605cywm
   8:     0x7ff274f4dd80 - option::Option<T>::unwrap::h861535042075806935
   9:     0x7ff274f4bb10 - main::h957fc2428efe99eefaa
  10:     0x7ff274f67140 - rust_try_inner
  11:     0x7ff274f67130 - rust_try
  12:     0x7ff274f644f0 - rt::lang_start::h46417f3fa3eb30a5w2z
  13:     0x7ff274f4c220 - main
  14:     0x7ff27413cdd0 - __libc_start_main
  15:     0x7ff274f4b9e0 - <unknown>
  16:                0x0 - <unknown>

main.rs

[sfackler]

You can set a breakpoint on rust_panic to have GDB stop on a panic!.

[kmcallister]

The second issue is #20978.

[jdm]

Could we put an int 3 instruction in rust_panic?

[sfackler]

The default SIGTRAP handler aborts the process.

[comex]

You could, at panic time, set SIGTRAP to SIG_IGN or whatever, then do the int3. Windows has something similar.

[kornelski]

That would be great, given that Rust's backtrace is less complete than lldb's: #24346

[steveklabnik]

Triage: no change.

[trufae]

I think that rust-lldb should run this script by default:

$ cat rust-lldb.rc
breakpoint set -n rust_panic

like this:

$  rust-lldb -s rust-lldb.rc target/debug/program
(lldb) run
(lldb) bt
...backtrace works...

[jimblandy]

You actually don't want to hard-code an int 3 into your code. GDB will recognize that as being not a breakpoint that it inserted, but rather part of the program itself—which is completely correct, but it means it's no different from a call to abort. (I believe GDB will then have trouble stepping over the int 3, because it believes it's an important instruction that must be executed, but each time it tries, the program gets a signal...)

Rather, now that GDB actually has real Rust support, you should add an empty, never-inlined function with a well-known name to panicking.rs, and have the panic process call that. Then you should modify GDB's Rust support to automatically set an internal breakpoint on that function, and handle panics in some useful way.

[tdaede]

Any thoughts on how to proceed on this? I can set a gdb script to auto run on start, but this is harder for people on my team who use IDEs. I can go submit patches to break on rust_panic by default to both gdb and lldb, or try to add support for doing this by default in each of the IDEs. The int 3 approach could work too - stepping over it isn't very important. Is rust_panic a sufficiently unique name?

[andrewrk]

Unsubscribing, because I solved this by making zig (which calls SIGABRT on panic).

I'm guessing people still want the issue open so I will leave it that way :)