[linux] 명령 줄 매개 변수가있을 때 GDB로 프로그램의 코어 덤프 파일을 분석하려면 어떻게합니까?

objdump+ gdb최소한의 실행 가능한 예

TL; DR :

• GDB는 앞에서 언급 한 실패한 줄을 찾는 데 사용될 수 있습니다. 명령 줄 매개 변수가있을 때 GDB로 프로그램의 코어 덤프 파일을 어떻게 분석합니까?
• 코어 파일에는 CLI 인수가 포함되어 있으며 다시 전달할 필요가 없습니다.
• objdump -s core 대량으로 메모리를 덤프하는 데 사용할 수 있습니다

이제 전체 교육 시험 설정을 위해 :

main.c

#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);
}

컴파일하고 실행하여 코어를 생성하십시오.

gcc -ggdb3 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
ulimit -c unlimited
rm -f core
./main.out

산출:

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

GDB는 세그멘테이션 오류가 발생한 정확한 행을 가리키며, 이는 디버깅하는 동안 대부분의 사용자가 원하는 것입니다.

gdb -q -nh main.out core

그때:

Reading symbols from main.out...done.
[New LWP 27479]
Core was generated by `./main.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000400635 in myfunc (i=1) at main.c:7
7           *(int*)(NULL) = i;
(gdb) bt
#0  0x0000000000400635 in myfunc (i=1) at main.c:7
#1  0x000000000040072b in main (argc=1, argv=0x7ffec6739328) at main.c:28

버기 라인 7로 바로 연결됩니다.

CLI 인수는 코어 파일에 저장되며 다시 전달할 필요가 없습니다.

특정 CLI 인수 질문에 대답하기 위해 cli 인수를 변경하면 다음과 같이 나타납니다.

rm -f core
./main.out 1 2

그러면 명령 변경없이 이전 bactrace에 반영됩니다.

Reading symbols from main.out...done.
[New LWP 21838]
Core was generated by `./main.out 1 2'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000564583cf2759 in myfunc (i=3) at main.c:7
7           *(int*)(NULL) = i; /* line 7 */
(gdb) bt
#0  0x0000564583cf2759 in myfunc (i=3) at main.c:7
#1  0x0000564583cf2858 in main (argc=3, argv=0x7ffcca4effa8) at main.c:2

이제 어떻게하는지 주목하십시오 argc=3. 따라서 이는 핵심 파일이 해당 정보를 저장함을 의미해야합니다. 나는 그것이 단지의 인수로 저장 같은데요 main은 다른 함수의 인수를 저장처럼.

코어 덤프가 전체 메모리를 저장하고 프로그램의 레지스터 상태를 저장해야하므로 현재 스택에서 함수 인수의 값을 결정하는 데 필요한 모든 정보가 있어야합니다.

덜 분명한 것은 환경 변수를 검사하는 방법입니다. 코어 덤프에서 환경 변수를 가져 오는 방법 환경 변수 도 메모리에 존재 하므로 objdump는 해당 정보를 포함하지만 모든 변수 를 한 번에 나열하는 방법을 잘 모르겠습니다. 다음과 같이 하나씩 테스트를 수행했습니다.

p __environ[0]

Binutils 분석

readelfand 같은 binutils 도구를 사용 하여 메모리 상태와 같은 파일에 objdump포함 된 정보를 대량 덤프 할 수 있습니다 core.

GDB는 대부분 / 모두 GDB를 통해 볼 수 있어야하지만 이러한 binutils 도구는 특정 사용 사례에 편리한보다 대량 접근 방식을 제공하는 반면 GDB는보다 대화식 탐색에 더 편리합니다.

먼저:

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..........

런에서 stdout 값과 정확히 일치합니다.

이것은 Ubuntu 16.04 amd64, GCC 6.4.0 및 binutils 2.26.1에서 테스트되었습니다.

답변

prompt > myprogram
Segmentation fault (core dumped)
prompt > gdb myprogram
...
(gdb) core core.pid
...

Syntax:
gdb <binary name> <generated core file>
Eg:
gdb l3_entity 6290-corefile

bash-4.1$ **gdb l3_entity 6290-corefile**

**Core was generated** by `/dir1/dir2/dir3/l3_entity **Program terminated with signal SIGABRT, Aborted.**
#0
#1
#2
#3
#4
#5
#6
#7
#8
#9
#10
(gdb)

(gdb) frame 8

(gdb) list +

(gdb) print thread_name