2010-04-23 17 views
25

Quando eseguo GDB su un programma che carica un .so che è collegato a pthreads, GDB segnala l'errore "Impossibile trovare nuovi thread: errore generico".gdb: Impossibile trovare nuovi thread: errore generico

Si noti che l'eseguibile che eseguo non è collegato con pthreads.

Eventuali indizi?

 
$ 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 

Questa funzione viene chiamata sul require 'ev':

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

Ulteriori informazioni sul mio sistema:

 
$ 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

Penso che questo possa essere correlato: http://thread.gmane.org/gmane.comp.gdb.devel/24205 alcuna soluzione alternativa? –

+0

Grazie per la domanda ... Sul mio sistema Ubuntu, non ho potuto ottenere il preload '/ usr/lib/i386-linux-gnu/libpthread.so' per funzionare quindi ho compilato Lua con pthread ... ;-(. – gaspard

risposta

28

Questo funziona anche:

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

5

Sembra che GDB non piace quando l'applicazione " improvvisamente "diventa dipendente da pthreads.

L'unica soluzione che ho trovato è quella di collegare l'applicazione host con pthreads.

che è piuttosto triste ...

+0

Quando dici "all'improvviso" intendi il caricamento dinamico in fase di esecuzione? –

+0

Questo ha risolto anche il mio problema, le mie librerie statiche/condivise dipendono da pthread ma non dal mio eseguibile quindi non lo linko. Tuttavia, una volta collegato il debugger si comporta correttamente ... Devo dire che la mia applicazione non crea alcun thread, tuttavia ha la possibilità di creare oggetti nella memoria locale del thread: –

+0

@Hassan: sì, all'improvviso = caricamento dinamico –

4

Ho scoperto che gdb possono connettersi al processo dopo la fase di esecuzione che collega alla libreria pthread è stata completata.

+0

A volte la ricompilazione non è un'opzione realistica quindi allegare dopo è probabilmente la soluzione più generale, grazie, questo thread ha risolto il mio problema –

26

a 64 bit dovrebbe fare questo:

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

Puoi anche creare un .gdbinit nella propria home directory che contiene il testo:

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

"Se si aggiunge la bandiera -lpth leggere gcc (o g ++) mentre si collega l'applicazione per il debug il problema sparisce. " Source

+1

Beh, questo è più o meno quello che ho scritto come risposta tre anni fa: "L'unica soluzione alternativa" trovato è quello di collegare l'applicazione host con pthreads. ";) –

Problemi correlati