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

[tbu-]

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.

[trufae]

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

…

On 10 Sep 2018, at 19:59, Tobias Bucher ***@***.***> 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.

[Hi-Angel]

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.

[BartMassey]

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

[andrewrk]

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

[joelgallant]

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

[Gusabary]

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

[Diegovsky]

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

[BartMassey]

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…

[Diegovsky]

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.