gdbおよび/または(実際のターゲットにデバッガがインストールされていないため)をcoredumpctl info
使用せずに呼び出しスタックをインポートできるように、coredumpを使用して印刷するときに、systemdに関数名を含む呼び出しスタックを含めるように設定しようとしています。coredumpctl debug
だからちょうど使用したいと思いますcoredumpctl info
。
Fedora 39を使用してパッケージをインストールし、tftp-server
tftpd(systemctl start tftp)を起動し、プロセスに送信してkill -SEGV
コアダンプをテストしました/usr/sbin/in.tftpd
。その後、このようにして生成されたコアダンプにプロセス内の関数名が含まれていることを確認しましたin.tftpd
(Fedoraはminidebuginfo
デフォルトで/を有効にします)。gnu_debugdata
ただし、デバッグシンボルでコンパイルされたテストCファイルで同じことを実行すると、テストコアダンプにn/a
私のプロセスの関数名が表示されます(フルデバッグシンボルとminidebuginfo
/のみを使用してみましたgnu_debugdata
)。
Fedoraパッケージでインストールされたバイナリの場合のように、私のアプリケーションでも正しいコアダンプを生成するにはどうすればよいですか?
テストコード(ファイル
test.c
):#include <stdio.h> #include <unistd.h> int test123() { printf("test123\n"); sleep(1); } int main() { for (;;) { test123(); } }
テストビルドファイル:
all: gcc ./test.c -o test-with-symbols -g
coredumpctl info
Fedoraでは問題ないようです(in.tftpd
関数名が表示されます):main
in.tftpd
$ 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
私のテストバイナリは関数名のn/a
代わりにそれを示しています。私はこれをFedora 39とUbuntu 22.04(Fedora 39のsystemdバージョン254、Ubuntu 22.04のsystemdバージョン249)でテストしました。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/[email protected]/app.slice/app-org.gnome.Terminal.slice/vte-spawn-07143dc2-3f50-4778-a60f-e027a4bb85e9.scope Unit: [email protected] 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