J'ai une application de test en C ++ Démarrage de plusieurs threads dans son L'un des threads fait quelque chose qui provoque une SEGFAULT et un COREDUMP est généré (Ulimit -C Unlimited a été définie précédemment).
Je ouvre le noyau avec La backtrage de ce thread solitaire semble correct, pas de choses étranges dedans.
Le système d'exploitation est Red Hat Enterprise 5.3, GDB-6.8. Main () , puis dort dans Main () Forever.
gdb et voir avec le thread Appliquer tous les filets BT ou info que je n'ai qu'un seul fil (commencé dans Main () ), qui est impossible car au moins le thread de Main () doit être fonctionnant aussi bien.
5 Réponses :
Êtes-vous vraiment sûr que c'est impossible? Peut-être que le problème est exactement lié au fait que le fil principal est sorti sans attendre les autres threads.
Après avoir démarré les threads, il fait pour (;;) SLEEP (1); donc je suis sûr que le fil principal ne quitte pas
Essayez d'exécuter votre application sous Valgrind. Maby Cela aidera à comprendre la cause de la crash.
Oui, Helgrind fournit des résultats et des remerciements pour la suggestion, mais ma question est différente.
Si vous n'avez pas SIGHANDLER pour SIGEGV avec Alt Stack, qui est un cas particulier, utilisez simplement la strace.
(strace homme)
(nous avons besoin de drapeau -f car le thread est toujours une portée globale de Linux. E.g. ~ Procs qui fonctionnent dans la même mémoire)
Voici l'exemple de sortie qui montre un fil qui s'est échappé avant le crash.
J'ai souligné la partie intéressante ...
clone (
= pile_fils 0x7fc1fc319ff0, drapeaux = CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_THREAD | CLONE_SYSVSEM | CLONE_SETTLS | CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID, parent_tidptr = 0x7fc1fc31a9e0, tls = 0x7fc1fc31a710, child_tidptr = 0x7fc1fc31a9e0) = 28757
[PID 28756] RT_SIGPROCMMASK (SIG_BLOCK, [CHLD],
[PID 28757] SET_ROBUST_LIST (0x7FC1FC31A9F0, 0x18
[PID 28756] <... RT_SIGPROCMMASS a repris> [], 8) = 0
[pid 28757] <... set_robust_list a repris>) = 0
[PID 28756] RT_SIGRACTION (SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
[PID 28757] MADVise (0x7FC1FB91A000, 10465280, MADV_DontNeed
[PID 28756] RT_SIGPROCMMASK (SIG_SETMASK, [],
[PID 28757] <... MADVise a repris>) = 0
[PID 28756] <... RT_SIGPROCMMASS a repris> NULL, 8) = 0
[PID 28757] _EXIT (0) =?
nanosleep ({1, 0}, 0x7fffce29c4b0) = 0
RT_SIGPROCMMASK (SIG_UNBLOCK, [ABRT], NULL, 8) = 0
TGKILL (28756, 28756, SIGABRT) = 0
--- Sigabrt (avorté) @ 0 (0) ---
+++ tué par Sigabrt (noyau largué) +++
avorté (noyau largué)
Faites maintenant un grep dans la sortie et voyez que les nombres de VS attachés détachés.
Si vous avez des threads en direct à la sortie (crash), je créerais une entrée de bugzilla (première recherche BugZilla OFC). strace -f myprogram
Processus 28757 attaché
Processus 28757 détaché
Ce sont des informations utiles et je l'ai essayée, mais malheureusement, le problème est une condition de race rare et cela ne se plantait pas avec la strace.
La raison pour laquelle vous ne voyez qu'un seul thread est que GDB n'est pas capable de distinguer les threads "par lui-même", il s'appuie sur une bibliothèque externe, le libthread_db , fourni par la bibliothèque de threads.
Cette bibliothèque doit être activée au début de la session de débogage afin de surveiller les activités de fil (naissance, décès, ...) et communique toutes les informations relatives au thread à GDB pendant l'exécution.
Vous devriez être capable de lire lorsque vous essayez de déboguer tout fichier compilé avec -LPTthread , mais gdb ne Essayez même d'activer libthread_db lorsque vous déboguez une vidée de noyau.
Je n'ai pas pu trouver un moyen d'activer libthread_db lors de l'analyse du fichier principal. J'ai remarqué sur d'autres OS (Debian) que GDB est capable de montrer des informations principales correctes sans [Débogage de fil à l'aide de Libthread_DB activé]
Il s'est avéré être Bug de noyau sous défaut Red Hat Enterprise 5.3, fixé dans la version de chapeau rouge ultérieure (5.4) - 1.110.1. RHSA-2009: 1193: Mise à jour importante de la sécurité et du correctif de bogues sur les systèmes 32 bits, les vidanges de base de certaines applications multithreadées n'incluent pas toutes les informations sur le thread. (BZ # 505322)
Kernel-2.6.18-164.EL5
Ce problème a-t-il commencé en 5.3 ou aussi dans les versions précédentes? Il semble assez grave de ne pas passer inaperçu, mais je ne peux pas le comprendre du bugzilla
@Aviv Je ne peux pas le comprendre non plus. Je pense qu'il n'y avait pas de tel problème dans les versions précédentes, mais c'était il y a longtemps et je ne peux pas dire avec certitude