Quelles sont les causes D'un Sigtrap dans une session de débogage?
dans mon programme c++ j'utilise une bibliothèque qui va " envoyer?"un Sigtrap sur une certaine opération quand Je suis en train de le déboguer (en utilisant gdb comme débogueur). Je peux alors décider si je veux continuer ou arrêter le programme. Si je choisis de continuer le programme fonctionne comme prévu, mais le réglage des points de rupture personnalisés après qu'un Sigtrap a été attrapé provoque le débogueur/programme de planter.
alors voici mes questions:
- quelles sont les causes d'un tel Sigtrap? Est-ce une ligne de code restante qui peut être retirée, ou est-ce causé par le débogueur quand il "trouve quelque chose qu'il n'aime pas" ?
- est un sigtrap, en général, une mauvaise chose, et si c'est le cas, pourquoi le programme fonctionne-t-il parfaitement quand je compileune version et non une version de débogage?
- que signifie un Sigtrap?
C'est une approche plus générale à une question que j'ai posté hier Boost Filesystem: le constructeur recursive_directory_iterator cause des problèmes de SIGTRAPS et de debug .
Je pense que ma question était loin d'être précise, et je ne veux pas que vous résolviez mon problème, mais aidez-moi (et j'espère d'autres personnes) à comprendre le contexte.
Merci beaucoup.
2 réponses
avec des processeurs qui prennent en charge les points de rupture d'instruction ou les points de veille de données, le débogueur demandera au CPU de surveiller les accès d'instruction à une adresse spécifique, ou les données lisent/écrivent à une adresse spécifique, puis exécutent à pleine vitesse.
quand le processeur détecte l'événement, il piège dans le noyau, et le noyau envoie SIGTRAP au processus en cours de débogage. Normalement, SIGTRAP tuerait le processus, mais parce qu'il est en cours de débogage, le débogueur être informé du signal et le gérer, principalement en vous laissant inspecter l'état du processus avant de poursuivre l'exécution.
avec des processeurs qui ne prennent pas en charge les points d'arrêt ou les watchpoints, l'ensemble de l'environnement de débogage est probablement fait par l'interprétation du code et l'émulation de la mémoire, qui est immensément plus lente. (J'imagine que des astuces astucieuses pourraient être faites en mettant des drapeaux pagetables pour interdire la lecture ou l'écriture, peu importe ce qui doit être piégé, et en laissant le noyau réparer les pagetables, signalant le débogueur, puis restreignant à nouveau les drapeaux de page. Cela pourrait probablement supporter un nombre quasi-arbitraire de points de surveillance et de points d'arrêt, et ne s'exécuter que légèrement plus lentement dans les cas où le point de surveillance ou le point d'arrêt n'est pas fréquemment utilisé.)
la question que j'ai placée dans le champ de commentaire semble ici à propos, seulement parce que Windows n'envoie pas réellement un SIGTRAP, mais plutôt le signal d'un point de rupture à sa propre manière native. Je suppose que quand vous êtes débogage des programmes, que les versions de débogage des bibliothèques système sont utilisées, et s'assurer que les accès mémoire semblent avoir du sens. Vous avez peut-être un bug dans votre programme qui est masqué à l'exécution, mais qui peut en fait causer d'autres problèmes ailleurs.
Je n'ai pas fait de développement sur Windows, mais peut-être pourriez-vous obtenir plus de détails en regardant à travers votre journal D'événements Windows?
en travaillant dans Eclipse avec minGW/gcc compilateur, j'ai réalisé qu'il réagit très mal avec les vecteurs dans mon code, résultant à un signal SIGTRAP peu clair et montrant parfois même un comportement anormal débuggeur (c.-à-d. sautant quelque part dans le code et l'exécution continue du code dans l'ordre inverse!).
j'ai copié les fichiers de mon projet dans le VisualStudio et résolu les problèmes, puis copié les changements de nouveau à eclipse et voila, a fonctionné comme un charme. Les raisons étaient similaires aux différences d'initialisation vectorielle avec les fonctions reserve() et resize (), ou en essayant d'accéder à des éléments hors des limites du tableau vectoriel.
Espérons que cela aidera quelqu'un d'autre.