Verstehen gdb Ausgabe im Falle von segfault

Question

Ich habe einen segfault in meinem Programm. Ich versuche, den backtrace Befehl der gdb zu verwenden, um den Fehler zu finden, aber leider verstehe ich nicht seine Ausgabe:

(gdb) bt 
#0 0x00007ffff1678480 in ??() from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 
#1 0x00007ffff171c11e in ??() from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 
#2 0x00007ffff17e565f in ??() from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 
#3 0x00007ffff17432e3 in ??() from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 
#4 0x00007ffff16580bf in ??() from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 
#5 0x00007ffff179e758 in ??() from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 
#6 0x00007ffff173cea8 in ??() from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 
#7 0x00007ffff6b8770a in start_thread (arg=0x7fffef352700) at pthread_create.c:333 
#8 0x00007ffff68bd82d in clone() at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 

Weiß jemand, wo die segfault herkommt? Zum Beispiel, warum ist die main Methode nicht in der backtrace Ausgabe aufgeführt?

Answer 1

Weiß jemand woher der segfault kommt?

Ja: GDB sagte Sie, wo es herkommt: eine unbenannte Funktion an der Adresse 0x7ffff1678480 innerhalb libnvidia-opencl.so.1

Zum Beispiel, warum die wichtigste Methode nicht in der Ausgabe des Backtrace aufgeführt?

Da der Absturz in einem anderen Thread als dem Hauptthread passiert ist.

Also, was sollten Sie tun?

Es gibt fast nichts, was Sie könnte tun, um diesen Absturz zu verstehen, weil Sie Anbieter-bereitgestellten und völlig undurchsichtigen Bibliothek verwenden.

Sie sollte jede OpenCL gehen ruft Ihr Programm ist (vorausgesetzt, es jeder tut) und stellen Sie sicher, dass die Argumente, die Sie liefern gültig sind und erfüllen die OpenCL API-Anforderungen.

Sie sollten auch (gdb) thread apply all where zu sehen, wo andere Threads sind. Vielleicht ist Ihr Haupt-Thread beendet, ohne OpenCL ordnungsgemäß heruntergefahren zu haben.

Sie können auch versuchen, Ihr Programm mit einer anderen (möglicherweise leistungsschwächeren) Open Source-OpenCL-Implementierung auszuführen (z. B. pocl). IF der Absturz reproduziert mit pocl, haben Sie viel leichter zu verstehen, was schiefgelaufen ist, wie Sie die Quelle untersuchen können und GDB wird Ihnen sagen genau wo in der Quelle das Problem aufgetreten ist.

Answer 2

am Boden starten und Aufarbeitung:

#8 0x00007ffff68bd82d in clone() at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 

ich eine Funktion namens clone sehen. Ich tippe man clone vor Ort und bekomme so etwas wie this.

Der vierte Abschnitt ist

Eine Verwendung des Klons() ist Threads zu implementieren: mehrere Threads von Steuerung in einem Programm, das gleichzeitig in einem gemeinsamen Speicherbereich ausgeführt.

, die relevant erscheint, wenn ich am nächsten Stapelrahmen aussehen

0x00007ffff6b8770a in start_thread (arg=0x7fffef352700) at pthread_create.c:333 

, wo ich eine Funktion namens start_thread in Modul pthread_create sehen. Hmm, thread, thread, ich habe das Wort schon irgendwo gesehen. Ich erinnere mich vor pthread_create irgendwo zu sehen, so gibt Sie man pthread_create ...

Nun, das erklärt, warum main nicht in dem Stack-Trace ist - dies ist der Stapel von einem untergeordneten Thread ist. Nicht der Hauptthread, in dem main läuft.

Beachten Sie, dass info threads eingeben können, um zu sehen, was andere Threads zu dem Zeitpunkt ausgeführt wurden, der Fehler aufgetreten ist, und thread 1 (oder was auch immer Nummer) auf einem anderen Thread zu wechseln und seine Stapel untersuchen.