2012-05-31 15 views
5

Estoy ejecutando un Linux basado en OpenEmbedded en una placa ARM, donde se está ejecutando mi aplicación. Solía ​​ejecutar kernel 2.6.35, gdb 6.8 y gcc 4.3. Últimamente he actualizado el sistema a kernel 2.6.37, gdb 7.4 (también intenté 7.3) y gcc 4.6.gdb: No se pueden encontrar nuevos hilos: error genérico después de la actualización del sistema

Ahora, mi aplicación ya no se puede depurar (en la placa ARM), cada vez que intento ejecutarlo en gdb aparece el error "gdb: No se pueden encontrar nuevos hilos: error genérico". La aplicación hace uso de pthreads y enlaza con pthreads (readelf lista libpthread.so.0 como una dependencia). Las soluciones sugeridas que encontré hasta ahora recomiendan vincular a pthread que ya estoy haciendo. La otra recomendación que encontré fue usar LD_PRELOAD =/lib/libpthread.so.0 que no hace ninguna diferencia para mí.

La depuración de las versiones x86 de la aplicación funciona sin problemas.

EDITAR: Para responder a las preguntas formuladas en la primera respuesta, estoy usando gdb en el destino (ARM), es decir, no cross-gdb. Tampoco he eliminado libpthread.so.0 (/lib/libpthread-2.9.so: ELF objeto compartido LSF de 32 bits, ARM, versión 1 (SYSV), vinculado dinámicamente (utiliza bibliotecas compartidas), para GNU/Linux 2.6. 16, no despojado). glibc se mantuvo en la versión 2.9 y la actualización involucrado recompilar la imagen Linux toda

Edit2: Extracción/lib/libthread-db * permite la depuración (con las consiguientes advertencias y obviamente algunas características no funcionarán)

Edit3: Usando conjunto de depuración libthread db-1 me sale:

Starting program: /home/root/app 
Trying host libthread_db library: libthread_db.so.1. 
Host libthread_db.so.1 resolved to: /lib/libthread_db.so.1. 
td_ta_new failed: application not linked with libthread 
thread_db_load_search returning 0 
Trying host libthread_db library: libthread_db.so.1. 
Host libthread_db.so.1 resolved to: /lib/libthread_db.so.1. 
[Thread debugging using libthread_db enabled] 
Using host libthread_db library "/lib/libthread_db.so.1". 
warning: Unable to set global thread event mask: generic error 
Warning: find_new_threads_once: find_new_threads_callback: cannot get thread info: generic error 
Found 0 new threads in iteration 0. 
Warning: find_new_threads_once: find_new_threads_callback: cannot get thread info: generic error 
Found 0 new threads in iteration 1. 
Warning: find_new_threads_once: find_new_threads_callback: cannot get thread info: generic error 
Found 0 new threads in iteration 2. 
Warning: find_new_threads_once: find_new_threads_callback: cannot get thread info: generic error 
Found 0 new threads in iteration 3. 
thread_db_load_search returning 1 
Warning: find_new_threads_once: find_new_threads_callback: cannot get thread info: generic error 
Found 0 new threads in iteration 0. 
Cannot find new threads: generic error 
(gdb) Write failed: Broken pipe 
+0

¿Tiene un libthread-db coincidente? –

+0

@Guy: He recompilado toda la imagen y esto debería coincidir. De lo contrario, ¿cómo puedo verificar si coincide? – dseifert

Respuesta

6

Hay dos causas comunes de este error:

  1. Usted tiene una falta de coincidencia entre una libpthread.so.0 nd libthread_db.so.1
  2. Usted ha despojado libpthread.so.0

Su mensaje no está del todo claro:

  1. está usando cruz GDB para depurar la aplicación que se ejecuta en ARM de un host x86?
  2. has actualizado (o reconstruido) glibc además de actualizar el kernel, etc.

Si despojado libpthread.so.0, entonces no hacen eso - libthread_db necesita para no ser despojado .

Si realiza una depuración cruzada, asegúrese de reconstruir libthread_db.so.1 en el host para que coincida con glibc en el destino.

Actualización:

not cross-debugging
did not strip libpthread

Por lo tanto, algo en su GDB o glibc parece haber sido roto.Usted puede tratar de ver lo que es por

  1. Putting eliminado libthread_db atrás, y
  2. (gdb) set debug libthread-db 1
  3. (gdb) run

Actualización 2:

warning: Unable to set global thread event mask: generic error

Esto significa que el BGF fue capaz de buscar la función td_ta_set_event en libthr ead_db, y lo llamó, pero la función devolvió un error. Una forma en que esto podría suceder es si GDB no pudo encontrar la función __nptl_threads_events en libpthread.so.0. Lo que hace este comando productos:

nm /lib/libpthread.so.0 | grep __nptl_threads_events 

Si ese mandato genera una salida, por ejemplo .:

000000000021c294 b __nptl_threads_events 

entonces no estoy seguro de qué más está fallando. Es probable que debas depurar el GDB para descubrir lo que está sucediendo.

Si, por otro lado, el grep anterior no produce ninguna salida, entonces es un problema con su cadena de herramientas: deberá averiguar por qué esa variable no aparece en su reconstrucción libpthread.so.0.

+0

No sé cómo debería haber ocurrido un desajuste, todo el sistema (incluido glibc en la versión 2.9) fue recompilado desde cero y debe coincidir. Tampoco quité libpthread y no estoy eliminando errores cruzados. – dseifert

+0

@dseifert Esto: '/lib/libpthread-2.9.so: ELF objeto compartido LSF de 32 bits, ARM, versión 1 (SYSV), enlazado dinámicamente (usa librerías compartidas), para GNU/Linux 2.6.16, no eliminado' no necesariamente significa que su 'libpthread' no está eliminado. ¿Cuál es la salida de 'nm /lib/libpthread-2.9.so | grep _version $ '? –

+0

Esto dice 0001181c r nptl_version – dseifert

Cuestiones relacionadas