How to get symbolized call-stacks with coredumpctl info?
1
vote
1
answer
499
views
I am trying to enable systemd coredumps containing call stacks with function names when printed with
coredumpctl info
, so that I can get a call stack without using gdb and/or coredumpctl debug
(since my real target has no debugger installed). Thus I want to use only coredumpctl info
.
Using Fedora 39, I installed the package tftp-server
, and tested coredumps by starting tftpd (systemctl start tftp), and sending kill -SEGV
to the process /usr/sbin/in.tftpd
. I then see that coredumps created that way contain the function names inside the in.tftpd
process (Fedora enables minidebuginfo
/gnu_debugdata
by default).
However, when I do the same thing using a test C file which I compiled with debug symbols, I see that my test coredumps show n/a
for the function names in my process (I tried with full debug symbols as well as with only minidebuginfo
/gnu_debugdata
).
What do I need to do so that my application also generates proper coredumps, like it is doing for binaries installed by Fedora packages?
* Test code (file test.c
):
-C
#include
#include
int test123()
{
printf("test123\n");
sleep(1);
}
int main()
{
for (;;) {
test123();
}
}
* Test Makefile:
all:
gcc ./test.c -o test-with-symbols -g
* coredumpctl info
of in.tftpd
looks good on Fedora (it shows the function name main
in in.tftpd
):
-shellsession
$ coredumpctl info 4335
PID: 4335 (in.tftpd)
UID: 0 (root)
GID: 0 (root)
Signal: 11 (SEGV)
Timestamp: Mon 2023-11-20 06:07:08 EST (1h 36min ago)
Command Line: /usr/sbin/in.tftpd -s /var/lib/tftpboot
Executable: /usr/sbin/in.tftpd
Control Group: /system.slice/tftp.service
Unit: tftp.service
Slice: system.slice
Boot ID: 954e4f02e86e4f6498987e2e202d0413
Machine ID: 28dd14ccbe5b46018201dd25d5a60e94
Hostname: localhost-live
Storage: /var/lib/systemd/coredump/core.in\x2etftpd.0.954e4f02e86e4f6498987e2e202d0413.4335.1700478428000000.zst (missing)
Package: tftp/5.2-41.fc39
build-id: 438daef3ffb345cc3c791def1ceba465865929f6
Message: Process 4335 (in.tftpd) of user 0 dumped core.
Module in.tftpd from rpm tftp-5.2-41.fc39.x86_64
Stack trace of thread 4335:
#0 0x00007ffb2640ef8e __select (libc.so.6 + 0x112f8e)
#1 0x00005578d0fde699 main (in.tftpd + 0x4699)
#2 0x00007ffb2632414a __libc_start_call_main (libc.so.6 + 0x2814a)
#3 0x00007ffb2632420b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2820b)
#4 0x00005578d0fdfa15 _start (in.tftpd + 0x5a15)
ELF object binary architecture: AMD x86-64
* codedumpctl info
of my test binary shows n/a
instead of function names. I tested this on Fedora 39 and on Ubuntu 22.04 (systemd version 254 on Fedora 39, systemd version 249 on Ubuntu 22.04):
-shellsession
liveuser@localhost-live:~/Downloads/test$ coredumpctl info 8485
PID: 8485 (test)
UID: 1000 (liveuser)
GID: 1000 (liveuser)
Signal: 11 (SEGV)
Timestamp: Mon 2023-11-20 07:26:38 EST (54s ago)
Command Line: ./test
Executable: /home/liveuser/Downloads/test/test
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-07143dc2-3f50-4778-a60f-e027a4bb85e9.scope
Unit: user@1000.service
User Unit: vte-spawn-07143dc2-3f50-4778-a60f-e027a4bb85e9.scope
Slice: user-1000.slice
Owner UID: 1000 (liveuser)
Boot ID: 954e4f02e86e4f6498987e2e202d0413
Machine ID: 28dd14ccbe5b46018201dd25d5a60e94
Hostname: localhost-live
Storage: /var/lib/systemd/coredump/core.test.1000.954e4f02e86e4f6498987e2e202d0413.8485.1700483198000000.zst (present)
Size on Disk: 17.9K
Message: Process 8485 (test) of user 1000 dumped core.
Stack trace of thread 8485:
#0 0x00007f8a5b4bd127 clock_nanosleep@GLIBC_2.2.5 (libc.so.6 + 0xd9127)
#1 0x00007f8a5b4cf9f7 __nanosleep (libc.so.6 + 0xeb9f7)
#2 0x00007f8a5b4e1333 sleep (libc.so.6 + 0xfd333)
#3 0x0000558c6c9a118a n/a (/home/liveuser/Downloads/test/test + 0x118a)
#4 0x0000558c6c9a119f n/a (/home/liveuser/Downloads/test/test + 0x119f)
#5 0x00007f8a5b40c14a __libc_start_call_main (libc.so.6 + 0x2814a)
#6 0x00007f8a5b40c20b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2820b)
#7 0x0000558c6c9a10a5 n/a (/home/liveuser/Downloads/test/test + 0x10a5)
ELF object binary architecture: AMD x86-64
Asked by Étienne
(153 rep)
Nov 20, 2023, 09:46 PM
Last activity: Sep 7, 2024, 07:33 PM
Last activity: Sep 7, 2024, 07:33 PM