GDB should break on panic

13c67d9
Opened by Andrew Kelley at 2023-04-05 17:45:39

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

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

    Steven Fackler at 2015-01-13 17:11:23

  2. The second issue is #20978.

    Keegan McAllister at 2015-01-14 04:30:49

  3. Could we put an int 3 instruction in rust_panic?

    Josh Matthews at 2015-01-14 15:52:46

  4. The default SIGTRAP handler aborts the process.

    Steven Fackler at 2015-01-14 18:02:48

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

    comex at 2015-03-13 00:23:55

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

    Kornel at 2015-04-12 10:51:52

  7. Triage: no change.

    Steve Klabnik at 2016-05-24 21:33:44

  8. 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...

    pancake at 2016-05-26 22:42:07

  9. 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.

    Jim Blandy at 2016-07-23 22:31:55

  10. 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?

    Thomas Daede at 2018-03-02 23:54:37

  11. 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 :)

    Andrew Kelley at 2018-03-03 06:51:03

  12. It seems the method to set a breakpoint on is now called rust_begin_unwind.

    EDIT: Nvm, it still seems to be rust_panic. I think I used gdb incorrectly.

    EDIT EDIT: Nvm again? It only seems to break if I set a breakpoint on both rust_begin_unwind and rust_panic. This seems weird.

    Tobias Bucher at 2018-09-10 17:58:13

  13. Not much obvious. Why not just int3 when under debugging?

    On 10 Sep 2018, at 19:59, Tobias Bucher notifications@github.com wrote:

    It seems the method to set a breakpoint on is now called rust_begin_unwind.

    — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

    pancake at 2018-09-10 18:11:22

  14. IMO the proper solution is to simply add abort() call in panic. This will make coredump if the system configured, or trigger gdb if it's connected.

    Konstantin K at 2018-12-08 15:58:51

  15. Would love to see this issue handled somehow. Just ran into it.

    Bart Massey at 2018-12-11 10:45:12

  16. IMO the proper solution is to simply add abort() call in panic. This will make coredump if the system configured, or trigger gdb if it's connected.

    That is how we do it in Zig:

    https://github.com/ziglang/zig/blob/5f5364ad73dc6c31e1e189596f407970f852701a/std/debug/index.zig#L171

    Andrew Kelley at 2018-12-11 19:21:56

  17. I wonder if b rust_panic is something that the rust-gdb helper script can do? (afaik it doesn't, just checked locally)

    Joel Gallant at 2018-12-17 23:03:59

  18. just use b rust_panic in gdb to set a breakpoint right before panic

    Tao Bocheng at 2021-04-19 05:28:10

  19. Reminder: if gdb says it does not exist, you're probably using a stripped build

    Diego Augusto at 2022-05-31 12:58:57

  20. Is there something wrong with @andrewrk's suggestion that rust_panic should always end by invoking abort()? It's what I would have expected given my experience with using other languages (and implementing their gdb support). I want this even if gdb is active, so that I can get a core dump to examine later…

    Bart Massey at 2022-05-31 16:16:57

  21. I agree with you, it should be default behaviour. I wonder if there is a reason for not using. I read somewhere Windows uses "fastfail" to panic, so it could be something to do with performance.

    Diego Augusto at 2022-06-01 00:12:55