With some Rust programs, generating a backtrace leads to an internal error in GDB: $ gdb target/debug/test GNU gdb (GDB) 12.1 Copyright (C) 2022 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-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://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 target/debug/test... warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts of file /home/hrniels/test/foo/target/debug/test. Use `info auto-load python-scripts [REGEXP]' to list them. (gdb) b main Breakpoint 1 at 0x9530 (gdb) run Starting program: /home/hrniels/test/foo/target/debug/test This GDB supports auto-downloading debuginfo from the following URLs: https://debuginfod.archlinux.org Enable debuginfod for this session? (y or [n]) n Debuginfod has been disabled. To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit. [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Breakpoint 1, 0x000055555555d530 in main () (gdb) bt ../../gdb/frame.c:2434: internal-error: inside_main_func: Assertion `block != nullptr' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- 0x563c6fccbb6b ??? 0x563c70009d44 ??? 0x563c700ccce3 ??? 0x563c6fde3fa2 ??? 0x563c6fef057d ??? 0x563c6fef283d ??? 0x563c6fdc2615 ??? 0x563c6ff7ace7 ??? 0x563c6fd01d74 ??? 0x563c6ffd1812 ??? 0x563c6fdc7bfc ??? 0x563c6fdc7c9d ??? 0x563c6fdb901f ??? 0x7fcb3b36c9df ??? 0x563c6fdbca3b ??? 0x563c6fdbcc23 ??? 0x563c6fdc7b2f ??? 0x563c700cd955 ??? 0x563c700cdd39 ??? 0x563c6fe8bd24 ??? 0x563c6fc37c04 ??? 0x7fcb3a22928f ??? 0x7fcb3a229349 ??? 0x563c6fc3e1e4 ??? 0xffffffffffffffff ??? --------------------- ../../gdb/frame.c:2434: internal-error: inside_main_func: Assertion `block != nullptr' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n I'm not exactly sure what the cause is, but the following Rust program can (hopefully) be used to reproduce the behavior: fn main() { println!("{}", std::env::var("RUST_LOG").unwrap_or_else(|_| "error".to_string())); } Note also that the problem goes away if I use `unwrap_or("error".to_string())` instead of `unwrap_or_else(|_| "error".to_string())`. So, maybe the closure plays a role here? In case it matters, I'm using Rust 1.61.0 (a028ae4 2022-04-29).
I couldn't make it fail here. I tried 1.61 and 1.62. It would be easy to patch around this assert, but I think we'd rather not do that without understanding the problem first.
There was indeed one thing missing as I just noticed when trying it on another system. Sorry for that. I have the following line in my ~/.gdbinit: set demangle-style gnu-v3 Without this line, the problem disappears.
I was able to reproduce it by changing that setting. I tend to think the "demangle-style" should not be settable. IMO it is a relic of the pre-v3 days, when maybe setting it by hand made sense .... but that doesn't really make sense any more, and the setting doesn't really do anything useful. Meanwhile, remove that from your .gdbinit and everything should be fine.
I can reproduce this without setting demangle-style (rustc 1.67.0 (fc594f156 2023-01-24)), same conditions as with Nils. I bisected gdb and it seems this was introduced in 7f4307436f.
(In reply to Michael Schmidt from comment #4) > I can reproduce this without setting demangle-style (rustc 1.67.0 (fc594f156 > 2023-01-24)), same conditions as with Nils. I bisected gdb and it seems this > was introduced in 7f4307436f. Maybe this is a dup of bug#30158 then. Can you try a gdb from git, either from the 13 branch or from master?
(In reply to Tom Tromey from comment #5) > (In reply to Michael Schmidt from comment #4) > > I can reproduce this without setting demangle-style (rustc 1.67.0 (fc594f156 > > 2023-01-24)), same conditions as with Nils. I bisected gdb and it seems this > > was introduced in 7f4307436f. > > Maybe this is a dup of bug#30158 then. > Can you try a gdb from git, either from the 13 branch or from master? Indeed, I tested bf3f6c02d7 (master) and 8067be0fc6 (gdb-13-branch) and both work fine.
Thanks, I'm going to close it then. *** This bug has been marked as a duplicate of bug 30158 ***