Closed agentzh closed 1 month ago
BTW, the core dumps were produced right after I ran the bpftime atttach PID
command in another terminal.
Unable to reproduce using bpftime load + bpftime start with example malloc
root@mnfe-pve:~/bpftime/example/malloc# gdb ./victim core
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 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:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
--Type <RET> for more, q to quit, c to continue without paging--
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./victim...
[New LWP 2572428]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./victim'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000070bfaca40267 in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
120 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0 0x000070bfaca40267 in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
#1 0x00005752a4c801ed in main (argc=1, argv=0x7fff426e9c98) at victim.c:14
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x70bfa562e2c0 (LWP 2572428) 0x000070bfaca40267 in __GI_kill ()
at ../sysdeps/unix/syscall-template.S:120
(gdb)
I'm testing the official
example/malloc
sample program on my side. Sometimes, the target process must crash and produce a core dump file. And I've noticed thatgdb
always hangs when loading such core dump files:Tried several different core dump files with both gdb 9.1 and 12.1. All produce the same thing. The only way to get the
gdb
to quit is to kill withSIGKILL
. Alas.It might be a gdb bug. Is this a known issue?