¿Qué causa un Sigtrap en una sesión de depuración

Question

En mi programa C++ estoy usando una biblioteca que "enviará?" un Sigtrap en ciertas operaciones cuando lo estoy depurando (usando gdb como depurador). Luego puedo elegir si deseo continuar o detener el programa. Si elijo continuar, el programa funciona como se espera, pero establecer puntos de interrupción personalizados después de que se haya capturado un Sigtrap hace que el depurador/programa se cuelgue.

Así que aquí están mis preguntas:

1. ¿Qué causa una SIGTRAP tales? ¿Es una línea de código sobrante que puede eliminarse o es causada por el depurador cuando "encuentra algo que no le gusta"?
2. ¿Es un sigtrap, en general, algo malo, y si es así, por qué el programa se ejecuta sin problemas cuando compilo una versión y no una versión de depuración?
3. ¿Qué indica un Sigtrap?

Este es un enfoque más general a una pregunta que he publicado ayerBoost Filesystem: recursive_directory_iterator constructor causes SIGTRAPS and debug problems.
Creo que mi pregunta fue muy específica, y no quiero que resuelvas mi problema sino que me ayudes (y espero que otros) a comprender el trasfondo.

Muchas gracias.

Answer 1

Con procesadores que soportan puntos de interrupción de instrucción o puntos de observación de datos, el depurador solicitará a la CPU que observe los accesos de instrucciones a una dirección específica, o lea/escriba datos en una dirección específica, y luego corra a toda velocidad.

Cuando el procesador detecta el evento, se quedará atrapado en el kernel, y el kernel enviará SIGTRAP al proceso que se está depurando. Normalmente, SIGTRAP aniquilaría el proceso, pero debido a que se está depurando, se le notificará la señal al depurador y lo manejará, principalmente al permitirle inspeccionar el estado del proceso antes de continuar con la ejecución.

Con procesadores que no admiten puntos de interrupción o puntos de observación, todo el entorno de depuración se realiza probablemente a través de la interpretación del código y la emulación de memoria, que es inmensamente más lenta. (Imagino que se pueden hacer trucos ingeniosos estableciendo indicadores de tabla de páginas para prohibir la lectura o escritura, lo que sea necesario atrapar, y dejar que el kernel arregle las tablas de páginas, señalizar el depurador y luego restringir los indicadores de página nuevamente. -un número arbitrario de puntos de observación y puntos de interrupción, y se ejecuta solo marginalmente más lento para los casos en que no se accede con frecuencia al punto de observación o al punto de interrupción.)

La pregunta que hice en el campo de comentarios parece pertinente aquí, solo porque Windows no es en realidad enviando un SIGTRAP, pero señalando un punto de ruptura en su propio modo nativo. Supongo que cuando está depurando programas, se utilizan las versiones de depuración de las bibliotecas del sistema y se asegura de que los accesos a la memoria parezcan tener sentido. Es posible que tenga un error en su programa que se empape en el tiempo de ejecución, pero de hecho puede estar causando problemas en otros lugares.

No he hecho desarrollo en Windows, pero ¿podría obtener más detalles mirando el registro de eventos de Windows?

Answer 2

Mientras trabajaba en Eclipse con el compilador minGW/gcc, me di cuenta de que reaccionaba muy mal con vectores en mi código, resultando en una señal SIGTRAP poco clara e incluso mostrando un comportamiento anormal del depurador (es decir, saltando en algún lugar del código y continuando la ejecución del código en orden inverso!).

He copiado los archivos de mi proyecto en VisualStudio y resolví los problemas, luego copié los cambios a eclipse y voila, funcionó como un amuleto. Las razones eran como las diferencias de inicialización de vector con las funciones reserve() y resize(), o tratando de acceder a elementos fuera de los límites de la matriz vectorial.

Esperamos que esto ayude a alguien más.