2010-04-23 24 views
25

Cuando ejecuto GDB contra un programa que carga un .so que está vinculado a pthreads, GDB informa del error "No se pueden encontrar nuevos hilos: error genérico".gdb: No se pueden encontrar nuevos hilos: error genérico

Tenga en cuenta que el ejecutable que ejecuto no está vinculado con pthreads.

¿Alguna pista?

 
$ 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 

Esta función se llama en require 'ev':

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

información adicional sobre mi 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

creo que esto puede estar relacionado: http://thread.gmane.org/gmane.comp.gdb.devel/24205 soluciones provisionales? –

+0

Gracias por la pregunta ... En mi sistema ubuntu, no pude hacer que la precarga '/ usr/lib/i386-linux-gnu/libpthread.so' funcionara, así que compilé Lua con pthread ... ;-(. – gaspard

Respuesta

28

Esto también funciona:

LD_PRELOAD =/lib/libpthread.so.0 GDB --args ./app usuarios de Ubuntu

5

Parece que el BGF no le gusta cuando la aplicación " de repente "se vuelve dependiente de pthreads".

La única solución que he encontrado es vincular la aplicación de host con pthreads.

que es bastante triste ...

+0

Cuando dices "de repente", ¿te refieres a la carga dinámica en tiempo de ejecución? –

+0

Esto también solucionó mi problema, mis bibliotecas estáticas/compartidas dependen de pthread pero no de mi ejecutable, por lo tanto no lo conecto. Sin embargo, una vez vinculado el depurador se comporta correctamente ... Debo mencionar que mi aplicación no crea subprocesos, sin embargo, tiene el potencial de crear objetos en la memoria local de subprocesos. –

+0

@Hassan: sí, de repente = carga dinámica –

4

He encontrado que el BGF pueden asociar al proceso después de que el tiempo de ejecución que une a la biblioteca pthreads ha completado.

+0

A veces recompilar no es una opción realista, por lo que adjuntar después es probablemente la solución más general. Gracias, este hilo resolvió mi problema. –

26

64 bits debe hacer esto:

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

Puede también crear un .gdbinit en su directorio que contiene este texto:

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

"Si se suma -lpth bandera lee a gcc (o g ++) mientras enlazas tu aplicación para que se elimine la falla, el problema desaparecerá ". Source

+1

Bueno, esto es más o menos lo que escribí como respuesta hace tres años: "La única solución que tengo". ve encontrado es vincular la aplicación de host con pthreads. ";) –

Cuestiones relacionadas