Points d'arrêt hors de nulle part lors du débogage avec GDB, à l'intérieur de NTDLL

Je recommanderais d'utiliser WINDBG, le débogueur Windows natif. Cela donnera une meilleure trace de pile spécialement pour les symboles lors de la transition vers le mode noyau.

wow, vous m'avez renvoyé 5 ans à quand j'ai utilisé GDB sur la plate-forme Linux :)

Vous pouvez empêcher GDB de se casser lors de la réception de Sigtrap avec la commande suivante: p>

handle SIGTRAP nostop

Bien que la question soit assez ancienne maintenant, voici quelques points qui pourraient aider quelqu'un qui viendrait ici après une recherche comme je l'ai fait:

Je viens de rencontrer ce problème lors du test sur Win7 une application développée par moi sur WinXP. Dans mon cas, il est lié à la fois à la surveillance de la gestion de la mémoire Windows 7 et à une mauvaise allocation de mémoire dans mon application.

Pour faire courte de l'histoire, dans le code de l'application, un bloc de mémoire qui a été mallocède par erreur (au lieu d'utiliser globallalloc () ) et a été libéré avec un GlobalFree () (ce qui ne va pas, car le tas de système a été accédé avec un pointeur à partir du pool de mémoire d'exécution C). Bien que cela provoque une fuite de mémoire (très petite dans cette affaire), elle était complètement inaperçue tout en effectuant des tests sur WinXP et l'ensemble du programme était apparemment correctement exécuté.

Maintenant, lorsqu'il est exécuté sur Win7, une fonction de surveillance de la mémoire appelée Le tas de défaillance tolérant (fth) détecte ce bogue de l'application (qui provoque une exception):

• En même temps, il s'agit de certaines informations via de sortieDebugstring () (ou peut-être dbgprint () ) à l'aide de la simple Débourview outil, ou par tout débogueur lors de la traçage de l'application. Ainsi, juste avant le signal reçu, vous pouvez voir quelque chose comme ça dans les messages:

  AVERTISSEMENT: HAUT [NOM_OF_YOUR.EXE]:

  Avertissement: adresse non valide spécifiée à RTLFreeeheap (006b0000, 006a3698)

  et (dans le cas où l'application est en cours de débogage), elle génère un point d'arrêt qui n'a aucun effet en dehors d'un débogueur, mais sinon cela devrait aider à pointer le problème. Ce point d'arrêt est montré comme le signal SIGTRAP par GDB .

  À ce stade, vous avez 2 alternatives:

  • Essayez de marcher sur la pile d'appels pour trouver les instructions défectueuses de votre code (malheureusement dans ce cas, le BT ou où Les commandes GDB ne peuvent pas montrer assez loin pour voir où Dans mon code, le tas a été débarrassé à tort - Si quelqu'un sait comment afficher la bonne pile d'appels à partir du module de départ au lieu de NTDLL, laissez-moi savoir )
  • Essayez de continuer lorsque FTH a la possibilité de corriger automatiquement la mémoire en tant que tentative de contourner votre bogue (ce correctif automatisme peut également se produire à l'avance sur la prochaine exécution de l'application)

    Pour ne pas arrêter au moment du problème du tas, levez MosHe Levi, vous pouvez définir un poignée SIGTRAP NOSTOP à l'invite GDB avant de démarrer l'application.

    Donc, en bref: oui, vous avez eu quelque chose qui ne va pas dans votre code relatif à la gestion de la mémoire, mais dans certains cas, il peut fonctionner sans crash. Mais en mode de débogage, le noyau essaie de vous mettre sur le chemin du problème.