Qu'est-ce que le message de trace GDB "0x0000000000000000 in ?? ()" signifier?

Question

Qu'est-ce que cela signifie quand il crée une trace avec la sortie suivante?

#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 ?? ()

Le programme s’est écrasé avec le signal standard 11, défaut de segmentation. Mon application est un programme FastCGI C ++ multi-thread fonctionnant sous FreeBSD 6.3, utilisant pthread comme bibliothèque de threading.

Il a été compilé avec -g et toutes les tables de symboles de ma source sont chargées, selon les sources d'informations.

Comme il est clair, aucun de mes codes n’apparaît dans la trace, mais l’erreur semble provenir de bibliothèques pthread standard. En particulier, qu'est-ce que c'est ?? () ????

EDIT : a finalement suivi le crash jusqu'à un accès mémoire non valide standard dans mon code principal. N'explique pas pourquoi la trace de la pile a été corrompue, mais c'est une question pour un autre jour:)

Answer 1

gdb n'a pas pu extraire l'adresse de retour appropriée de pthread_mutexattr_init; il a une adresse de 0. Le "??" est le résultat de la recherche de l'adresse 0 dans la table des symboles. Il ne peut pas trouver un nom symbolique, donc il affiche par défaut un "??"

Malheureusement, je ne sais pas pourquoi il n'a pas pu extraire la bonne adresse de retour.

Answer 2

Quelque chose que vous avez causé a fait planter la bibliothèque de threads. Étant donné que la bibliothèque de threads elle-même n'est pas compilée avec les symboles de débogage (-g), elle ne peut pas afficher le fichier de code source ni le numéro de ligne sur lequel la panne s'est produite. De plus, comme il s'agit de threads, la pile d'appels ne pointe pas vers votre fichier. Malheureusement, ce sera un bug difficile à localiser, vous devrez parcourir votre code et essayer de le préciser lorsque le crash se produit.

Answer 3

Assurez-vous de compiler avec les symboles de débogage. (Pour gcc, je pense que c'est l'option -g). Dans ce cas, vous devriez pouvoir obtenir des informations plus intéressantes sur GDB. N'oubliez pas de l'éteindre lors de la compilation de la version de production.

Answer 4

Il se peut que quelque chose me manque, mais cela ne signifie-t-il pas que quelqu'un utilise NULL comme pointeur de fonction?

#include <stdio.h>

typedef int (*funcptr)(void);

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

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

Ceci produit le même style de trace que si vous l'exécutez dans gdb:

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

C’est un crash assez étrange cependant ... pthread_mutexattr_init fait rarement plus qu’allouer une structure de données et le memset . Je chercherais quelque chose d'autre. Y at-il une possibilité de bibliothèques de threading incompatibles ou quelque chose. Ma connaissance de BSD est un peu dépassée, mais il y avait des problèmes autour de cela.

Answer 5

Peut-être que le bug qui a provoqué le crash a cassé la pile (parties écrasées de la pile)? Dans ce cas, la trace pourrait être inutile; aucune idée de ce qu'il faut faire dans ce cas ...