Coredump-Analyse?

[nobody0]

Nachdem mir ein Programm nur dann abstürzt, wenn ich es statisch linke, will ich mal den coredump analysieren, aber wie analysiert man denn einen Coredump? :confused:

[Jasper]

mit 'gdb -c <corefile>'. das binary sollte mit '-g' kompiliert worden sein.


-j

[nobody0]

Aha, danke, aber das sagt mir nicht viel:

> gdb -c ./core.11755
GNU gdb 6.2.1
...
Core was generated by `/home/nobody0/c/8fa/1/relais -on'.
Program terminated with signal 11, Segmentation fault.
#0 0x0804a4fc in ?? ()
(gdb) list
No symbol table is loaded. Use the "file" command.

Wie kann ich das Ding noch analysieren? :confused:

[nobody0]

Also ddd liefert eine genauere Ausgabe:

Core was generated by /home/nobody0/c/8fa/1/relais -on'.
Program terminated with signal 11, Segmentation fault.
#0 0x0804a4fc in __pthread_manager ()

Also ist der Bug in __pthread_manager ().
Ich werde mal versuchen den Bug den Entwicklern zu mailen. Mal sehen welche Email-Adr. die haben.

[panzi]

Der Bug ist nicht notwendiger Weiße in dieser Funktion. Der Segmentationfault ist zwar dort aufgetreten, aber wenn du z.B. ein strcpy( NULL, "xxx" ) aufrufst, dann tritt der Segmentationfault auch in strcpy auf, der Fehler ist aber in DEINEM Code.

[RapidMax]

Das erste das ich nach "gdb -c corefile" eingebe ist "bt". Es liefert dann einen Backtrace des Stack, d.h. man sieht die Aufrufshierachie der Funktionen:


#include <stdio.h>
void foo(int* a) { printf("Test: %d\n", *a); }
void bar(int* a) { foo(a); }
void baz(int* a) { bar(a); }
int main() {
baz(NULL);
return 0;
}

(gdb) bt
#0 0x0804838d in foo (a=0x0) at test.c:3
#1 0x080483b2 in bar (a=0x0) at test.c:5
#2 0x080483c5 in baz (a=0x0) at test.c:6
#3 0x080483e3 in main () at test.c:8

Manchmal kommt es vor, dass der Stack überschrieben wird. Dann hat man kein, oder kein korrekter Stackdump. Hier helfen z.B. die canaries, wie sie mit neueren Version von gcc aktiviert werden können.

Gruss, Andy