Linuxでデバッグ用のコアファイルを表示するには？

Question 1

GDBの最小実行可能例

GDBは以前に以下で言及されました：https://unix.stackexchange.com/a/89934/32558この答えを承認することを検討してください。

シンプルc

int myfunc(int i) {
    *(int*)(0) = i;
    return i - 1;
}

int main(int argc, char **argv) {
    (void)argv;
    int i = argc * 2;
    int ret = myfunc(i);
    return ret;
}

コンパイルして実行してコアを生成します。

gcc -ggdb3 -std=c99 -Wall -Wextra -pedantic -o simple.out simple.c

コアファイルを作成するには、まず現在の端末で実行する必要があります。

ulimit -c unlimited

これは「サイズ制限なしでコアファイルダンプ」を意味します。これは、コアファイルに競合が発生したプロセスのメモリ全体が含まれ、サイズが非常に大きい可能性があるために発生します。

テストのために、Ubuntu 16.04から既存のコアファイルを削除する必要があります（TODO必須？忘れました）。

rm -f core

Ubuntu 22.04からコアファイルを入手するには、apportと戦う必要があります。https://askubuntu.com/questions/1349047/where-do-i-find-core-dump-files-and-how-do-i-view-and-analyze-the-backtrace-st/1442665#1442665たとえば、

echo 'core' | sudo tee /proc/sys/kernel/core_pattern

その後、プログラムを実行します。

./simple.out

端末には以下が含まれます。

Segmentation fault (core dumped)

コアファイルが作成されました。 Ubuntu 16.04では、ファイル名は次のとおりです。

core

Ubuntu 22.04では、echo 'core' | sudo tee /proc/sys/kernel/core_patternファイル名は次のとおりです。

core.<pid>

ここで、PIDはプロセスID、つまり数値です。例:

core.162152

Linuxカーネルの更新がサフィックスの追加を開始したためだと思います.pid。することを確認してください。

これで、コアファイルを次のように使用できます。

gdb simple.out core
gdb simple.out core.162152

今、私たちはGDBセッションに入ります。これは、プログラムがクラッシュしたときとまったく同じ状況ですが、プログラムがすぐに終了するため、「続行」できません。

#0  0x0000557097e0813c in myfunc (i=2) at simple.c:2
2           *(int*)(0) = i; /* line 7 */
(gdb) bt
#0  0x0000557097e0813c in myfunc (i=2) at simple.c:2
#1  0x0000557097e0816b in main (argc=1, argv=0x7ffcffc4ba18) at simple.c:9
(gdb) up
#1  0x0000557097e0816b in main (argc=1, argv=0x7ffcffc4ba18) at simple.c:9
9           int ret = myfunc(i);
(gdb) p argc
$1 = 1

したがって、実行後にbt競合が発生したときにコードがどこにあったかをすぐに知ることができ、時にはエラーを修正するのに十分です。

例に示すように、クラッシュ時にプログラムメモリを調べてエラーの原因を特定できます。プロセス仮想メモリはすべてコアファイルに含まれています。

Ubuntu 16.04および22.04 amd64でテストされました。

GDB経由で直接プログラムを実行することもできます。

問題が簡単に再現可能で（つまり、迅速かつ決定的に競合が発生した場合）、コマンドラインを簡単に制御できる場合（つまり、変更を望まない、または変更できない他のプログラムから呼び出されたプログラムではない）、最善の方法は次のとおりです。と同じです。 GDBを介してプログラムを実行します。

gdb -ex run simple.out

シグナルが受信されると、GDBはデフォルトでシグナルの原因によって中断され、コアファイルを使用するのと同じ状況になります。

直接Binutils分析

よりよく理解するために、GDBなしでコアファイルの内容を観察してみましょう。私たちができるので。

物事の相関関係を確認できるように、独自のメモリアドレスを印刷するプログラムを作成しましょう。

メインプログラム

#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int myfunc(int i) {
    *(int*)(NULL) = i; /* line 7 */
    return i - 1;
}

int main(int argc, char **argv) {
    /* Setup some memory. */
    char data_ptr[] = "string in data segment";
    char *mmap_ptr;
    char *text_ptr = "string in text segment";
    (void)argv;
    mmap_ptr = (char *)malloc(sizeof(data_ptr) + 1);
    strcpy(mmap_ptr, data_ptr);
    mmap_ptr[10] = 'm';
    mmap_ptr[11] = 'm';
    mmap_ptr[12] = 'a';
    mmap_ptr[13] = 'p';
    printf("text addr: %p\n", text_ptr);
    printf("data addr: %p\n", data_ptr);
    printf("mmap addr: %p\n", mmap_ptr);

    /* Call a function to prepare a stack trace. */
    return myfunc(argc);
}

プログラム出力：

text addr: 0x4007d4
data addr: 0x7ffec6739220
mmap addr: 0x1612010
Segmentation fault (core dumped)

最初：

file core

coreファイルが実際にELFファイルであることを知らせます。

core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from './main.out'

そのため、一般的なbinutilsツールを使用してより直接チェックできます。

早く見てくださいELF規格実際には、専用ELFタイプがあることを示しています。

Elf32_Ehd.e_type == ET_CORE

詳細なフォーマット情報は以下で確認できます。

man 5 core

それから：

readelf -Wa core

ファイル構造に関するいくつかのヒントを提供します。メモリは通常のプログラムヘッダに含まれているようです。

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  NOTE           0x000468 0x0000000000000000 0x0000000000000000 0x000b9c 0x000000     0
  LOAD           0x002000 0x0000000000400000 0x0000000000000000 0x001000 0x001000 R E 0x1000
  LOAD           0x003000 0x0000000000600000 0x0000000000000000 0x001000 0x001000 R   0x1000
  LOAD           0x004000 0x0000000000601000 0x0000000000000000 0x001000 0x001000 RW  0x1000

コメント領域にはより多くのメタデータもあります。特にprstatusPCを含む:

Displaying notes found at file offset 0x00000468 with length 0x00000b9c:
  Owner                 Data size       Description
  CORE                 0x00000150       NT_PRSTATUS (prstatus structure)
  CORE                 0x00000088       NT_PRPSINFO (prpsinfo structure)
  CORE                 0x00000080       NT_SIGINFO (siginfo_t data)
  CORE                 0x00000130       NT_AUXV (auxiliary vector)
  CORE                 0x00000246       NT_FILE (mapped files)
    Page size: 4096
                 Start                 End         Page Offset
    0x0000000000400000  0x0000000000401000  0x0000000000000000
        /home/ciro/test/main.out
    0x0000000000600000  0x0000000000601000  0x0000000000000000
        /home/ciro/test/main.out
    0x0000000000601000  0x0000000000602000  0x0000000000000001
        /home/ciro/test/main.out
    0x00007f8d939ee000  0x00007f8d93bae000  0x0000000000000000
        /lib/x86_64-linux-gnu/libc-2.23.so
    0x00007f8d93bae000  0x00007f8d93dae000  0x00000000000001c0
        /lib/x86_64-linux-gnu/libc-2.23.so
    0x00007f8d93dae000  0x00007f8d93db2000  0x00000000000001c0
        /lib/x86_64-linux-gnu/libc-2.23.so
    0x00007f8d93db2000  0x00007f8d93db4000  0x00000000000001c4
        /lib/x86_64-linux-gnu/libc-2.23.so
    0x00007f8d93db8000  0x00007f8d93dde000  0x0000000000000000
        /lib/x86_64-linux-gnu/ld-2.23.so
    0x00007f8d93fdd000  0x00007f8d93fde000  0x0000000000000025
        /lib/x86_64-linux-gnu/ld-2.23.so
    0x00007f8d93fde000  0x00007f8d93fdf000  0x0000000000000026
        /lib/x86_64-linux-gnu/ld-2.23.so
  CORE                 0x00000200       NT_FPREGSET (floating point registers)
  LINUX                0x00000340       NT_X86_XSTATE (x86 XSAVE extended state)

objdumpすべてのメモリは簡単にダンプできます。

objdump -s core

これには以下が含まれます。

Contents of section load1:

 4007d0 01000200 73747269 6e672069 6e207465  ....string in te
 4007e0 78742073 65676d65 6e740074 65787420  xt segment.text 

Contents of section load15:

 7ffec6739220 73747269 6e672069 6e206461 74612073  string in data s
 7ffec6739230 65676d65 6e740000 00a8677b 9c6778cd  egment....g{.gx.

Contents of section load4:

 1612010 73747269 6e672069 6e206d6d 61702073  string in mmap s
 1612020 65676d65 6e740000 11040000 00000000  egment..........

これは私たちの実行の標準出力値と正確に一致します。

Ubuntu 16.04 amd64、GCC 6.4.0、binutils 2.26.1でテストされました。

Mozillarrの逆デバッグは究極の「コアファイル」です。

コアファイルを使用すると、中断時にスタックを確認できます。

しかし、一般的に実際にすべきことは、時間をさかのぼって失敗の根本原因をより詳細に把握することです。

素晴らしいMozilla rrを使用するとこれを行うことができますが、トレースファイルが大きくなり、パフォーマンスがわずかに低下します。

例は次のとおりです。https://stackoverflow.com/questions/1470434/how-does-reverse-debugging-work/53063242#53063242

また、見ることができます

https://stackoverflow.com/questions/8305866/how-do-i-analyze-a-programs-core-dump-file-with-gdb-when-it-has-command-line-pa

Answer