Was bedeutet die GDB Backtrace Nachricht „0x0000000000000000 in ?? ()" bedeuten?

Question

Was bedeutet es, wenn es einen 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 Standard-Signal 11, Segmentierungsfehler abgestürzt. Meine Anwendung ist ein Multi-Threaded FastCGI C ++ Programm, das auf FreeBSD 6.3, Pthread als Threading-Bibliothek verwendet wird.

Es hat sich mit -g und alle Symboltabellen für meine Quelle geladen werden, nach Informationsquellen zusammengestellt.

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

Bearbeiten : schließlich den Absturz aufgespürt zu einem Standard ungültigen Speicherzugriff in meinem Haupt-Code. Erklärt nicht, warum wurde der Stack-Trace beschädigt, aber das ist eine Frage für einen anderen Tag:)

Answer 1

war gdb nicht in der Lage die richtige Absenderadresse von pthread_mutexattr_init zu extrahieren; es bekam eine Adresse von 0. Der „??“ ist das Ergebnis des Nachschlagens Adresse 0 in der Symboltabelle. Es kann nicht einen symbolischen Namen finden, so dass es eine Standard druckt „??“

Leider rechts offhand ich weiß nicht, warum es nicht die richtige Absenderadresse extrahieren kann.

Answer 2

Etwas, das Sie die Threading-Bibliothek hat zum Absturz bringen. Da die Threading-Bibliothek selbst nicht mit Debugging-Symbolen (-g) kompiliert wird, kann es nicht die Quellcodedatei oder Zeilennummer zeigt der Absturz passierte auf. Darüber hinaus, da es Threads, wird der Call-Stack nicht auf die Dateien verweisen zurück. Leider wird dies ein harter Fehler sein aufzuspüren, du wird müssen durch den Code zu gehen und versuchen, und zu verengen, wann genau der Absturz passiert.

Answer 3

Stellen Sie sicher, dass Sie mit Debug-Symbolen kompilieren. (Für gcc denke ich, dass die Option -g ist). Dann sollten Sie in der Lage sein, mehr interessante Informationen aus GDB zu erhalten. Vergessen Sie nicht, um sie auszuschalten, wenn Sie die Serienversion kompiliert werden.

Answer 4

Ich könnte etwas fehlen, aber ist das nicht indikativ für jemand NULL als Funktionszeiger mit?

#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 ausführen:

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

obwohl

Das ist ein ziemlich eigenartiger Sturz ... pthread_mutexattr_init selten tut etwas mehr als eine Datenstruktur zuordnen und es memset. Ich würde für etwas anderes suchen geht. Gibt es eine Möglichkeit, nicht übereinstimmen Threading-Bibliotheken oder so etwas. Mein BSD Wissen ist etwas veraltet, aber es verwendet dabei, um Fragen rund um.

Answer 5

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