Was bedeutet die GDB-Rückverfolgungsnachricht "0x000000000000000000 in ??()"?

Question

Was bedeutet es, wenn es ein Backtrace mit der folgenden Ausgabe gibt?

#0 0x00000008009c991c in pthread_testcancel() from /lib/libpthread.so.2 
#1 0x00000008009b8120 in sigaction() from /lib/libpthread.so.2 
#2 0x00000008009c211a in pthread_mutexattr_init() from /lib/libpthread.so.2 
#3 0x0000000000000000 in ??() 

Das Programm ist mit einem Standardsignal 11, Segmentierungsfehler, abgestürzt. Meine Anwendung ist ein Multi-Thread-FastCGI C++ - Programm, das unter FreeBSD 6.3 läuft und pthread als Threading-Bibliothek verwendet.

Es wurde mit -g kompiliert und alle Symboltabellen für meine Quelle werden laut Infoquellen geladen.

Wie klar ist, erscheint keiner meiner tatsächlichen Code in der Ablaufverfolgung, sondern der Fehler scheint von Standard Pthread Bibliotheken stammen. Insbesondere was ist ??() ????

EDIT: schließlich verfolgt den Absturz auf einen Standard ungültigen Speicherzugriff in meinem Hauptcode. Erklärt nicht, warum der Stack-Trace beschädigt wurde, aber das ist eine Frage für einen anderen Tag :)

Answer 1

gdb konnte die richtige Absenderadresse nicht aus pthread_mutexattr_init extrahieren; es hat eine Adresse von 0. Das "??" ist das Ergebnis der Suche nach Adresse 0 in der Symboltabelle. Es kann keinen symbolischen Namen finden, daher wird ein Standard "??"

Leider weiß ich nicht direkt, warum es nicht die richtige Absenderadresse extrahieren konnte.

Answer 2

Stellen Sie sicher, dass Sie mit Debug-Symbolen kompilieren. (Für gcc denke ich, das ist die Option -g). Dann sollten Sie in der Lage sein, interessantere Informationen aus GDB zu bekommen. Vergessen Sie nicht, es auszuschalten, wenn Sie die Produktionsversion kompilieren.

Answer 3

Vielleicht hat der Fehler, der den Absturz verursacht hat, den Stapel durchbrochen (überschriebene Teile des Stapels)? In diesem Fall könnte das Backtrace nutzlos sein; keine Ahnung, was in diesem Fall zu tun ist ...

Answer 4

Etwas, was Sie verursacht haben, die Threading-Bibliothek zum Absturz gebracht. Da die Threading-Bibliothek selbst nicht mit Debugsymbolen (-g) kompiliert wird, kann sie die Quellcodedatei oder die Zeilennummer, an der der Absturz aufgetreten ist, nicht anzeigen. Da es sich um Threads handelt, verweist der Aufruf-Stack außerdem nicht auf Ihre Datei. Leider wird dies ein schwerer Fehler sein, den du aufspüren musst, du musst deinen Code durchgehen und versuchen, einzugrenzen, wenn genau der Absturz passiert.

Answer 5

Ich könnte etwas fehlen, aber ist dies nicht bezeichnend für jemanden mit NULL als Funktionszeiger?

#include <stdio.h> 

typedef int (*funcptr)(void); 

int 
func_caller(funcptr f) 
{ 
    return (*f)(); 
} 

int 
main() 
{ 
    return func_caller(NULL); 
} 

Dies erzeugt den gleichen Stil eines Backtrace, wenn Sie es in gdb laufen:

rivendell$ gcc -g -O0 foo.c -o foo 
rivendell$ gdb --quiet foo 
Reading symbols for shared libraries .. done 
(gdb) r 
Starting program: ... 
Reading symbols for shared libraries . done 

Program received signal EXC_BAD_ACCESS, Could not access memory. 
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 
0x00000000 in ??() 
(gdb) bt 
#0 0x00000000 in ??() 
#1 0x00001f9d in func_caller (f=0) at foo.c:8 
#2 0x00001fb1 in main() at foo.c:14 

Dies obwohl ein ziemlich eigenartiger Sturz ist ... pthread_mutexattr_init selten tut etwas mehr als eine Datenstruktur zuordnen und memset es. Ich würde nach etwas anderem suchen. Gibt es eine Möglichkeit von nicht übereinstimmenden Threading-Bibliotheken oder so etwas? Mein BSD-Wissen ist ein wenig altmodisch, aber es gab Probleme in dieser Hinsicht.