Wie kann ich analysieren ein Programm auf die core-dump-Datei mit GDB, wenn es command-line-Parameter?

Mein Programm arbeitet so:

exe -p param1 -i param2 -o param3

Knallte es und erzeugt einen core-dump-Datei core.pid.

Möchte ich analysieren, die core-dump-Datei

gdb ./exe -p param1 -i param2 -o param3 core.pid

Aber GDB erkennt die Parameter der EXE-Datei als GDB-Eingang.

Wie kann ich analysieren, einen core-dump-Datei in dieser situation?

Sind Sie sicher, dass Ihre exe ist nicht ein shell-Skript (um einige Variablen, etc..), wie zB firefox ist auf Linux?

InformationsquelleAutor Treper | 2011-11-29

161

Können Sie den Kern mit gdb in vielerlei Hinsicht, aber die übergabe von Parametern, die übergeben werden, um die ausführbare Datei für den gdb ist nicht die Art, wie der core-Datei. Dies könnte auch der Grund sein, haben Sie die Fehler. Sie können verwenden Sie die core-Datei in der folgenden Weise:

gdb <executable> <core-file> oder gdb <executable> -c <core-file> oder

gdb <executable>
...
(gdb) core <core-file>

Bei Verwendung von core-Datei, die Sie nicht haben, um Argumente übergeben werden. Das crash-Szenario gezeigt wird in gdb (geprüft mit gdb in der Version 7.1 unter Ubuntu) .
Zum Beispiel:

$ ./crash -p param1 -o param2
Segmentation fault (core dumped)
$ gdb ./crash core
GNU gdb (GDB) 7.1-ubuntu
...
Core was generated by `./crash -p param1 -o param2'. <<<<< See this line shows crash scenario
Program terminated with signal 11, Segmentation fault.
#0  __strlen_ia32 () at ../sysdeps/i386/i686/multiarch/../../i586/strlen.S:99
99  ../sysdeps/i386/i686/multiarch/../../i586/strlen.S: No such file or directory.
    in ../sysdeps/i386/i686/multiarch/../../i586/strlen.S
(gdb)

Wenn Sie möchten, um Parameter an die ausführbare Datei zum Debuggen in gdb verwenden --args.

Zum Beispiel:

$ gdb --args ./crash -p param1 -o param2
GNU gdb (GDB) 7.1-ubuntu
...
(gdb) r
Starting program: /home/@@@@/crash -p param1 -o param2

Program received signal SIGSEGV, Segmentation fault.
__strlen_ia32 () at ../sysdeps/i386/i686/multiarch/../../i586/strlen.S:99
99  ../sysdeps/i386/i686/multiarch/../../i586/strlen.S: No such file or directory.
    in ../sysdeps/i386/i686/multiarch/../../i586/strlen.S
(gdb)

Mann Seiten wird hilfreich sein, um zu sehen, andere gdb Optionen.

InformationsquelleAutor another.anon.coward

29

Einfache Benutzung von GDB zum Debuggen coredump-Dateien:
```
gdb <executable_path> <coredump_file_path>
```
Coredump-Datei für einen "Vorgang" angelegt wird, als "Kern.pid" - Datei.
Nachdem Sie in die gdb-Eingabeaufforderung (bei der Ausführung des obigen Befehls), geben;
```
...
(gdb) where
```
Diese erhalten Sie mit den Informationen auf dem stack, wo Sie analayze die Ursache für Absturz/Fehler.
Anderen Befehl, für gleiche Zwecke;
```
...
(gdb) bt full
```
Dies ist dasselbe wie oben. Durch Konvention, listet er die ganzen Stapel info (die letztlich zu dem Absturz-Ort).

InformationsquelleAutor parasrish
20

Überspringen Sie einfach die params, gdb braucht Sie nicht:
```
gdb ./exe core.pid
```
- Aber das funktioniert nicht. Die gdb-Ausgabe Warnung: core-Datei entsprechen möglicherweise nicht den angegebenen ausführbaren Datei. Failed to read a valid object file image from memory.
- "core-Datei, die möglicherweise nicht mit angegeben ausführbare Datei". Hast du das ändern der exe-Datei nach dem es produziert der Kern? Hast du vielleicht es wieder aufzubauen mit verschiedenen Kommandozeilen-Optionen? Es ist sehr wichtig, um den GDB der genaue gleiche Binärdatei, produziert der Kern. Wenn Sie nicht, erhalten Sie, garbage out.
- Auch stellen Sie sicher, dass die Binärdatei übergeben wird, um den gdb ist nicht ausgezogen. Sie können ausführen " die Datei <binary-name>", die zeigt, dass es entfernt wird oder nicht.
InformationsquelleAutor Nialscorva
10

Vom RMS ist der gdb-Debugger-Tutorial:
```
prompt > myprogram
Segmentation fault (core dumped)
prompt > gdb myprogram
...
(gdb) core core.pid
...
```
Stellen Sie sicher, dass die Datei wirklich eine core Bild -- überprüfen Sie es mit file.

InformationsquelleAutor Brian Cain
9

Einen etwas anderen Ansatz erlauben wird, Sie zu überspringen GDB vollständig. Wenn alles, was Sie wollen, ist ein backtrace, die linux-spezifische utility 'catchsegv' fangen SIGSEGV und display ein backtrace.

InformationsquelleAutor Rob Latham

objdump + gdb minimal lauffähigen Beispiel

TL;DR:

objdump -s core dump memory
GDB zu finden, scheitern Linie, zuvor erwähnt: Wie kann ich analysieren ein Programm auf die core-dump-Datei mit GDB, wenn es command-line-Parameter?

Jetzt für das gesamte Bildungs-test-setup:

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

Kompilieren und ausführen zu generieren core:

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

Ausgabe:

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

GDB stellen Sie uns die genaue Zeile, wo der segfault passiert ist, was die meisten Nutzer wollen beim Debuggen:

gdb -q -nh main.out core

dann:

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

die Punkte, die uns direkt in die buggy Linie 7.

Binutils Analyse

Erste:

file core

sagt uns, dass die core - Datei ist eigentlich eine ELF-Datei:

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

weshalb wir in der Lage sind, zu inspizieren, um es direkt mit den üblichen binutils-tools.

Einen schnellen Blick auf die ELF standard zeigt, dass es eigentlich ein ELF-Typ, um es gewidmet:

Elf32_Ehd.e_type == ET_CORE

Weiteren Informationen zum format finden Sie unter:

man 5 core

Dann:

readelf -Wa core

gibt einige Hinweise über die Datei-Struktur. Erinnerung erscheint, enthalten sein in regelmäßige Programm-Header:

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

und es gibt einige mehr Metadaten vorhanden in einer notes-Bereich. Vor allem, ich denke, der PC muss da sein (TODO bestätigen):

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 können ganz einfach sichern Sie alle Speicher mit:

objdump -s core

enthält:

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

passt genau mit dem stdout-Wert in unserem Lauf.

Getestet in Ubuntu 16.04 amd64, GCC 6.4.0, binutils 2.26.1.

InformationsquelleAutor Ciro Santilli 新疆改造中心996ICU六四事件

3

Ist es egal, ausführbare Argumente haben oder nicht, Zu GDB auf alle binäre mit einem generierten core-Datei, die Syntax ist unten.
```
Syntax: 
gdb <binary name> <generated core file>    
Eg: 
gdb l3_entity 6290-corefile    
```
lassen Sie mich nehmen Sie das folgende Beispiel für mehr Verständnis.
```
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)
```
Aus der obigen Ausgabe können Sie sich vorstellen, etwas über core, ob es ein NULL-Zugriff oder SIGABORT etc..

Diese Nummern #0 bis #10 werden die stack-frames der GDB. Diese stack-frames nicht Ihre binäre. in der oben 0 - 10 frames wenn Sie vermuten, dass etwas falsch wählen, dass der Rahmen
```
(gdb) frame 8 
```
Nun zu sehen, mehr details über ihn:
```
(gdb) list + 
```
Problem weiter zu untersuchen, können Sie drucken die vermutete variable Werte hier an diesem Punkt der Zeit.
```
(gdb) print thread_name 
```
InformationsquelleAutor Venkatakrishna Kalepalli
0

Können Sie analysieren die core-dump-Datei mit "gdb" - Befehl.
```
 gdb - The GNU Debugger

 syntax:

 # gdb executable-file core-file

 ex: # gdb out.txt core.xxx 
```
Dank.
- out.txt ist eine ausführbare Datei? Das scheint wie eine irreführende Datei-Erweiterung.
InformationsquelleAutor Ranjithkumar T
0

Geben Sie einfach den Befehl
```
$ gdb <Binary> <codeDump>
```
oder
```
$ gdb <binary>

$ gdb) core <coreDump>
```
Keine Notwendigkeit, irgendeine Befehl Linie argument. Der code dump erzeugt durch frühere übung.

InformationsquelleAutor KB Arora

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.