[Bug] with gef gdb crashes on "attach pid" command with connected gdbserver under multi-process mode

[2512500960]

GEF+GDB version

GEF: (Standalone)
Blob Hash(/home/kollubuntu/.gdbinit-gef.py): 8dc57b700e3c1c85822449033a01c94dfae9e4a6
SHA256(/home/kollubuntu/.gdbinit-gef.py): 63d3e10d38a367c3e4d37de8e0701bcdff2a4e7c9a0a4ec5d83ccb8b2fe6188d
GDB: 12.1
GDB-Python: 3.10

Operating System

Ubuntu 22.04.1 LTS

Describe the issue you encountered

1. connected to gdbserver with command "target extended-remote localhost:6234", everything looks fine (tried gdbserver of version 9 and 12)
2. get the pid of target process: "info os processes", still fine
3. run "attach (pidofprocess)", gdb crashes
4. start the same gdb without gef, then evety step is same, "attach" command works fine

Do you read the docs and look at previously closed issues/PRs for similar cases?

Yes

Architecture impacted

• X86
• X64
• ARM
• ARM64
• MIPS
• MIPS64
• PPC
• PPC64
• RISCV

Describe your issue. Without a proper reproduction step-by-step, your issue will be ignored.

0. connected to gdbserver with command "target extended-remote localhost:6234"
1. get the pid of target process: "info os processes"
2. run "attach (pidofprocess)"

Minimalist test case

No response

Additional context?

when gdb crashes, output goes like:

gdb crash log

Attaching to program: /home/kollubuntu/Desktop/xxxxxxxxxxxxxxx, process 570
/build/gdb-ZgDh0V/gdb-12.1/gdb/thread.c:85: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x55eba4404077 ???
0x55eba4768a64 ???
0x55eba4768ca0 ???
0x55eba48b80e4 ???
0x55eba4724ad1 ???
0x55eba452485c ???
0x55eba45275f5 ???
0x55eba463fe00 ???
0x7f3947957c01 ???
0x7f39478a49b7 ???
0x7f39479ef81e ???
0x7f39478a2eed ???
0x7f39479ef81e ???
0x7f39478a2eed ???
0x7f39479ef81e ???
0x7f3947910597 ???
0x7f394790f463 ???
0x7f394790f8f2 ???
0x55eba463d957 ???
0x55eba463d740 ???
0x55eba4643372 ???
0x55eba4581151 ???
0x55eba472643f ???
0x55eba4687d8d ???
0x55eba4696ecc ???
0x55eba4562484 ???
0x55eba4439654 ???
0x55eba472f394 ???
0x55eba45079a4 ???
0x55eba4507d43 ???
0x55eba45084c6 ???
0x7f3947ec4e0d ???
0x55eba4506a95 ???
0x55eba4508374 ???
0x55eba450668b ???
0x55eba48b8815 ???
0x55eba48b8caa ???
0x55eba45c436c ???
0x55eba45c6054 ???
0x55eba435c15f ???
0x7f3946e3fd8f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f3946e3fe3f __libc_start_main_impl
../csu/libc-start.c:392
0x55eba4361bf4 ???
0xffffffffffffffff ???

This is a bug, please report it. For instructions, see:
https://www.gnu.org/software/gdb/bugs/.

[1] 306450 IOT instruction (core dumped) gdb init

[hugsy]

https://hugsy.github.io/gef/commands/gef-remote/

[2512500960]

thanks for helping,
with no luck, gdb still crashes, anything missed?

[hugsy]

try getting the symbols for gdb to get more info. there's currently not enough info for us to help, gef-remote works fine on all my test environments

[2512500960]

The gdb I used is from apt repo, so I compiled gdb 12.1 from source with symbol info reversed, then tried the gef-remote command in the new compiled gdb, it doesn't crash, readlly confusing.

[hugsy]

readlly confusing

I get that, gdb can be stupidly confusing at times. if you really wanna dig into that bug you'll need symbols (on ubuntu that's not a problem) but even then might be tough to get to the root cause

[Grazfather]

This is caused by a GDB bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=31303

ghidra found a way to work around it: NationalSecurityAgency/ghidra@c9a5102#diff-c744e6d179eb7f2fdc2cf789c9d392cd128fa130faa751a578a4393a030b84b6R283-R288
and so did pwndbg: https://discord.com/channels/@me/1346958292995412110/1404891506371727452

We can look into doing the same.