GDB ne peut pas afficher la pile et affiche "#1 0x0000000000000000 in ? ? ()"

Question

J'ai un programme C++ multithread qui se bloque dans certains cas rares. Le problème est difficile à reproduire et je ne peux le faire que sur une machine distante. La méthode que je souhaite utiliser pour résoudre ce problème est la suivante

1. exécuter le programme
2. attendre l'impasse
3. lui envoyer un signal d'abandon pour générer un core dump
4. copier le dumping sur ma machine locale
5. utiliser gdb pour le déboguer

Je n'ai pas gdb sur la machine distante et je ne peux rien y installer. Le problème est que lorsque je débogue le core dump (obtenu à partir d'un processus bloqué ou en cours d'exécution sur la machine distante), le back-trace de la plupart des threads ne montre que :

(gdb) bt
#0  pthread\_cond\_wait () at ../nptl/sysdeps/unix/sysv/linux/x86\_64/pthread\_cond\_wait.S:261
#1  0x0000000000000000 in ?? ()

J'utilise un binaire lié statiquement qui est compilé avec les options "-g -O1". Lorsque j'interromps un processus du même binaire sur ma machine locale, gdb peut extraire la pile entière du core dump et il n'y a pas de problème de ce type (je ne peux cependant pas reproduire le blocage). Ma machine distante est SLES et ma machine locale est ubuntu.

Une idée ?

Editer :

J'ai trouvé quelqu'un d'autre avec le même problème, mais toujours pas de solution : http://groups.google.com/group/google-coredumper/browse_thread/thread/2ca9bcf9465d1050 (Je n'utilise pas google coredumper, mais il semble que google coredumper échoue avec la même erreur, ce qui suggère que le problème vient peut-être de SLES 11).

Answer 1

Notez que vous pouvez également utiliser gcore pour créer un fichier core sans interrompre le processus. Avez-vous essayé d'exécuter pstack sur l'hôte distant (en supposant qu'il soit installé) pour voir si vous pouvez obtenir un backtrace de cette façon ?

Sinon, si les objets partagés utilisés par votre application sont différents sur votre hôte local et votre hôte distant, gdb ne sera pas en mesure de faire correspondre les décalages de mémoire correctement et le backtrace sera probablement confus. Si vous êtes en mesure de copier tous les fichiers .so de l'hôte distant à un endroit local, je pense que vous pouvez demander à gdb de les lire à la place des versions normalement installées.

EDIT : essayez de lancer pstack sur votre machine de construction et voyez s'il peut détecter une pile.

Answer 2

Quel est l'âge de votre glibc ? Vous avez peut-être oublié ceci :

commit ad2be8527ac0f19f129fc4519d823cbe48239c78
Author: Ulrich Drepper <drepper@redhat.com>
Date:   Sun Apr 13 08:36:19 2003 +0000

    Update.

        * sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: Add unwind info.
        * sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S: Likewise.
        * sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S: Likewise.