Bug 29298

Summary:	Internal error when debugging Rust programs
Product:	gdb	Reporter:	Nils Asmussen <nils>
Component:	backtrace	Assignee:	Not yet assigned to anyone <unassigned>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	m100, tromey
Priority:	P2
Version:	12.1
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:	2022-08-05 00:00:00
Project(s) to access:		ssh public key:

Description Nils Asmussen 2022-06-29 14:10:40 UTC

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

Comment 1 Tom Tromey 2022-07-06 16:07:35 UTC

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.

Comment 2 Nils Asmussen 2022-07-06 18:15:54 UTC

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.

Comment 3 Tom Tromey 2022-08-05 14:29:10 UTC

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.

Comment 4 Michael Schmidt 2023-03-22 10:51:00 UTC

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.

Comment 5 Tom Tromey 2023-03-22 16:10:52 UTC

(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?

Comment 6 Michael Schmidt 2023-03-22 16:46:40 UTC

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

Comment 7 Tom Tromey 2023-03-22 20:30:00 UTC

Thanks, I'm going to close it then.

*** This bug has been marked as a duplicate of bug 30158 ***