2012-01-23 12 views
8

Tengo una aplicación que estoy depurando y estoy tratando de entender cómo funciona gdb y por qué no puedo pasar por la aplicación a veces. El problema que estoy experimentando es que gdb se bloqueará y que el proceso al que está conectado pasará a un estado de inactividad cuando revise el programa. Después de que gdb se cuelga y tengo que matarlo para liberar el terminal (ctrl-C no funciona, tengo que hacer esto desde una ventana de terminal diferente obteniendo el id de proceso para esa sesión de gdb y usando kill -9).¿Por qué colgaría gdb?

Supongo que gdb se cuelga porque está esperando que la aplicación se detenga en la siguiente instrucción y de alguna manera la aplicación finalizó la ejecución sin que gdb lo identificara. Pero eso solo es especulación por el comportamiento que he observado hasta ahora. Entonces mi pregunta es si alguien ha visto este tipo de comportamiento antes y/o podría sugerir cuál podría ser la causa. Creo que eso podría ayudarme a mejorar mi estrategia de depuración.

En caso de que importe, estoy usando g ++ 4.4.3, gdb 7.1, ejecutándose en Ubuntu 10.04 x86_64.

+0

¿Hay alguna caja de prueba mínima que pueda dar? Quiero decir, tal como está escrito, es muy difícil responder por qué podría estar sucediendo, aparte de "podría ser porque gdb tiene un error". – derobert

+0

gracias por la sugerencia. En este momento, la aplicación tiene mucho código de biblioteca, pero veré si puedo hacer un pequeño caso de prueba que pueda publicar como ejemplo. –

+1

Yo recomendaría usar un 'gdb' más reciente. La versión actual es ** 7.3 ** e hicieron un gran progreso. (y por cierto, usar un 'g ++' más reciente, es decir 4.6.2 también sería útil, ya que GCC también avanzó en la información de depuración). –

Respuesta

4

Diría que el proceso depurado no se quedará inactivo si fue la causa del bloqueo. Cada vez que GDB ha completado un paso, debe actualizar las expresiones que requirió para imprimir. Puede incluir los siguientes punteros y, en algunos casos, puede fallar allí (aunque no recuerdo un verdadero "bloqueo"). También suele tratar de actualizar su seguimiento de pila. Si el seguimiento de la pila se ha dañado y ya no es coherente, podría quedar atrapado en un ciclo sin fin. Adjuntar gdb a strace para ver qué tipo de actividad está ocurriendo durante el hang podría ser una buena manera de ir un paso más allá en la solución del problema.

(por ejemplo, acceso a las fuentes a través de un NFS/montaje SSHFS -que ya no está trabajando es una de las razones más frecuentes para GDB para colgar, aquí: P)

+0

gracias por los pensamientos. ¿Puedes dar más detalles sobre lo que quieres decir con "unir gdb a strace"? –

+0

Me refiero a ejecutar 'strace -p \' pidof gdb \ '' en un terminal y estudiar el resultado. Debe presentar todas las llamadas al sistema ejecutadas por el programa. – PypeBros

+0

gracias por la sugerencia. Todavía no descubrí cuál es el motivo del problema, pero es útil observarlo. La última llamada al sistema donde gdb se cuelga es 'wait4 (26066,' (para esta ejecución, el PID varía, por supuesto). Mientras tanto, un listado con ps -a muestra que el proceso 26066 está 'difunto'. –

1

que tenía un problema similar y lo resolvió mediante el envío de una CONT señal al proceso que se depura.