2010-04-23 3 views
25

Lorsque je lance GDB sur un programme qui charge un .so lié à pthreads, GDB signale une erreur "Impossible de trouver de nouveaux threads: erreur générique".gdb: Impossible de trouver de nouveaux threads: erreur générique

Notez que l'exécutable que je cours n'est pas lié avec pthreads.

Des indices?

 
$ gdb --args lua -lluarocks.require 
GNU gdb (GDB) 7.0-ubuntu 
Copyright (C) 2009 Free Software Foundation, Inc. 
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it. 
There is NO WARRANTY, to the extent permitted by law. Type "show copying" 
and "show warranty" for details. 
This GDB was configured as "x86_64-linux-gnu". 
For bug reporting instructions, please see: 
<http://www.gnu.org/software/gdb/bugs/>... 
Reading symbols from /usr/bin/lua...(no debugging symbols found)...done. 
(gdb) run 
Starting program: /usr/bin/lua -lluarocks.require 
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio 
> require 'ev' 
[Thread debugging using libthread_db enabled] 
Cannot find new threads: generic error 
(gdb) q 
A debugging session is active. 

    Inferior 1 [process 4986] will be killed. 

Quit anyway? (y or n) y 

Cette fonction est appelée sur require 'ev':

http://github.com/brimworks/lua-ev/blob/master/lua_ev.c#L25-65

informations supplémentaires sur mon système:

 
$ uname -a 
Linux localhost 2.6.31-20-generiC#58-Ubuntu SMP Fri Mar 12 04:38:19 UTC 2010 x86_64 GNU/Linux 
 
$ lsb_release -a 
No LSB modules are available. 
Distributor ID: Ubuntu 
Description: Ubuntu 9.10 
Release: 9.10 
Codename: karmic 
+0

Je pense que cela peut être lié: http://thread.gmane.org/gmane.comp.gdb.devel/24205 solutions de contournement? –

+0

Merci pour la question ... Sur mon système ubuntu, je n'ai pas pu obtenir le préchargement '/ usr/lib/i386-linux-gnu/libpthread.so' pour fonctionner alors j'ai compilé Lua avec pthread ... ;-(. – gaspard

Répondre

28

Cela fonctionne aussi:

LD_PRELOAD =/lib/libpthread.so.0 gdb --args ./app

5

Il semble que GDB n'aime pas quand l'application " soudainement "devient dépendante de pthreads.

La seule solution de contournement que j'ai trouvée consiste à lier l'application hôte avec pthreads.

Ce qui est assez triste ...

+0

Quand vous dites "soudainement" voulez-vous dire le chargement dynamique à l'exécution? –

+0

Cela a également résolu mon problème, mes librairies statiques/partagées dépendent de pthread mais pas de mon exécutable donc je ne le lierai pas. Cependant, une fois lié le débogueur se comporte correctement ... Je devrais mentionner que mon application ne crée pas de threads, mais qu'elle a le potentiel de créer des objets dans la mémoire locale du thread –

+0

@Hassan: oui, soudainement = chargement dynamique –

4

J'ai trouvé que gdb peut joindre au processus après la liaison d'exécution à la bibliothèque pthreads terminée.

+0

Parfois, la recompilation n'est pas une option réaliste. C'est probablement la solution la plus générale.Merci, ce fil a résolu mon problème –

26

64 bits Les utilisateurs d'Ubuntu devrait faire ceci:

LD_PRELOAD=/lib/x86_64-linux-gnu/libpthread.so.0 gdb --args ./app 
13

Vous pouvez créer également un .gdbinit dans votre répertoire contenant ce texte:

set env LD_PRELOAD /lib/libpthread.so.0 
1

« Si vous ajoutez drapeau -lpth lire à gcc (ou g ++) tout en liant votre application à déboguer le problème disparaître. " Source

+1

Eh bien, c'est plus ou moins ce que j'ai écrit comme réponse il y a trois ans: "La seule solution de contournement I" Nous avons trouvé que lier l'application hôte avec pthreads. ";) –

Questions connexes