Les points d'arrêt sortis de nulle part lors du débogage avec gdb, à l'intérieur de ntdll

J'ai fait un programme très simple qui automatise certaines choses pour moi.Je l'ai écrit en c++ et il tourne sur Windows. Lors du débogage avec GDB de l'intérieur de l'IDE Codeblocks , je reçois beaucoup de points d'arrêt de nulle part. Je n'ai aucune idée de ce qui pourrait être à l'origine de ce problème. Les points d'arrêt semblent être liées à des problèmes de mémoire ... depuis quand je fixe une fuite de mémoire j'avais détecté, le nombre de points d'arrêt a obtenu beaucoup moins.

La chose exacte que gdb me dit:

 Program received signal SIGTRAP, Trace/breakpoint trap.
 In ntdll!TpWaitForAlpcCompletion () (C:\Windows\system32\ntdll.dll)

- Je obtenir ce à plusieurs reprises à l'intérieur de mon programme. Je pense que je pourrais être en train de faire quelque chose de très mal, même si le programme semble fonctionner très bien et il accomplit ce que je veux faire. Quelqu'un peut-il me dire quel est le problème puisque je ne sais pas où chercher? Aussi, si ce n'est pas un problème, personne ne sait comment le désactiver car cela m'empêche d'accéder aux points d'arrêt, je me suis fixé?

Merci d'avance!

EDIT: (Ajout de la sortie de GDB où la commande):
Où puis-je vérifier que chacune de ces fonctions, donc je peux voir ce que je fais de mal?

#0  0x76fefadd in ntdll!TpWaitForAlpcCompletion () from C:\Windows\system32\ntdll.dll
#1  0x0028e894 in ?? ()
#2  0x76fb272c in ntdll!RtlCreateUserStack () from C:\Windows\system32\ntdll.dll
#3  0x00657fb8 in ?? ()
#4  0x00657fb8 in ?? ()
#5  0x76f4b76a in ntdll!RtlDowncaseUnicodeChar () from C:\Windows\system32\ntdll.dll
#6  0x02070005 in ?? ()
#7  0x00000b10 in ?? ()
#8  0x0028e8dc in ?? ()
#9  0x76ff0b37 in ntdll!TpQueryPoolStackInformation () from C:\Windows\system32\ntdll.dll
#10 0x038b0000 in ?? ()
#11 0x00657fb8 in ?? ()
#12 0x76f4b76a in ntdll!RtlDowncaseUnicodeChar () from C:\Windows\system32\ntdll.dll
#13 0x6e6e9a5e in ?? ()
#14 0x038b0000 in ?? ()
#15 0x038b0000 in ?? ()
#16 0x00000000 in ?? ()

source d'informationauteur Lefteris

  1. 16

    Alors que la question est assez vieux maintenant, voici quelques points qui pourraient aider quelqu'un qui serait venu ici après une recherche comme je l'ai fait:

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

    De faire l'histoire courte, dans le code de l'application, un bloc de mémoire qui a été malloced par erreur (au lieu d'utiliser GlobalAlloc()) et a été libéré avec un GlobalFree() (ce qui est faux, comme le système de tas est accessible avec un pointeur de la C de la mémoire d'exécution de la piscine). Tout cela est à l'origine d'une (très petite) fuite de mémoire, il a été complètement inaperçu lors de tests sur WinXP et de l'ensemble du programme était en cours d'exécution apparemment correctement.

    Maintenant, lorsqu'il est exécuté sur Win7, une mémoire de la fonction de surveillance appelé Tolérance De Pannes Tas (CINQUIÈME) détecte ce bug de l'application (qui est à l'origine une exception) :

    • En même temps, elle est sortie quelques infos via OutputDebugString() (ou peut-être DbgPrint()) qui peuvent être affichées à l'aide de la simple DebugView outil, ou par un débogueur lors du suivi de la demande. Ainsi, juste avant le signal reçu, vous pouvez voir quelque chose comme ça dans les messages :

      avertissement: SEGMENT[name_of_your.exe]:

      avertissement: adresse non Valide spécifié à RtlFreeHeap( 006B0000, 006A3698 )

    • Et (dans le cas de l'application est en cours de débogage) il affiche un point d'arrêt qui n'a pas d'effet en dehors d'un débogueur, mais autre chose qui devrait nous aider à le problème. Ce point d'arrêt est indiqué que le signal SIGTRAP par GDB.

    À ce stade, vous avez 2 solutions :

    • essayez de marcher sur la pile des appels pour trouver le fautif instruction dans votre code (malheureusement, dans ce cas, le bt ou where gdb commandes ne peuvent pas montrer assez loin pour voir où, dans mon code, le segment a été libéré à tort - si quelqu'un sait comment afficher correctement la pile des appels à partir du module de départ au lieu de ntdll, laissez-moi savoir)
    • essayer de continuer comme CINQUIÈME a la capacité d'auto-magiquement patch dans la mémoire comme une tentative pour contourner un bug (que automagic patch peut également se produire à l'avance sur le prochain lancement de l'application)

    Pour ne pas s'arrêter au moment des tas de problème, comme Moshe Levi dit, vous pouvez définir un handle SIGTRAP nostop à la GDB confirmation avant de commencer l'application.

    Donc en bref : oui, vous n'avez quelque chose de mal dans votre code par rapport à la gestion de la mémoire, mais dans certains cas, il peut fonctionner sans s'écraser. Mais en mode debug, le noyau essaie de vous mettre sur le chemin du problème.

  2. 7

    Wow, vous m'avez envoyé de retour 5 ans lorsque j'ai utilisé gdb sur la plate-forme linux 🙂

    vous pouvez empêcher gdb pour briser lors de la réception de SIGTRAP avec la commande suivante:

    handle SIGTRAP nostop

    Mais je suis avec steve ici, Essayez de WinDbg à la place. Il a été construit spécialement pour windows.

  3. 2

    Je vous recommande d'utiliser WinDBG, natif de windows débogueur. Cela permettra de mieux les traces de pile en particulier pour les symboles lors de la transition vers le mode noyau.

  4. 1

    Que je vient de vivre ce plantage lors de l'utilisation de gcc/mingw avec Qt Creator.

    J'ai eu d'autres problèmes, y compris des variables qui semblait être mauvais (décalage de 6 octets).
    Dans mon cas, il s'est avéré être un pragma pack qui fait des ravages sur le code.

    J'ai eu ceci:

    #pragma pack(1)
typedef struct SomeStruct
{
... //structure
} SomeStruct;

    ... mais je n'ai pas la terminer avec un pragma pack() appel pour mettre fin à l'emballage de 1 après la structure et de retourner à la valeur par défaut de l'octet d'alignement/de l'emballage. Ajoutant qu'il fixe:

    #pragma pack(1)
typedef struct SomeStruct
{
... //structure
} SomeStruct;
#pragma pack() //<<-- with this line the heap corruption problem was stopped