Haltepunkte aus dem Nichts beim Debuggen mit gdb, innerhalb ntdll

StackOverflow https://stackoverflow.com/questions/1621059

  •  06-07-2019
  •  | 
  •  

Frage

habe ich ein sehr einfaches Programm, das einige Dinge für me.I automatisiert es in c geschrieben ++ und es läuft auf Windows. Während es mit GDB debuggen aus dem Inneren des Codeblocks IDE, erhalte ich viele Haltepunkte aus dem Nichts. Ich habe keine Ahnung, was dieses Problem verursachen könnte. Die Haltepunkte scheinen mit Speicherproblemen verbunden zu sein ... da, wenn ich ein Speicherleck fixierte ich erkannt hatte, bekam die Stützpunkte Zahl deutlich weniger.

Die genaue Sache, die gdb sagt mir, ist: 

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

Ich bekomme so viele viele Male in meinem Programm. Ich denke, dass ich etwas sehr falsch machen könnte, obwohl das Programm ganz gut zu laufen scheint und es erreicht, was ich will, es zu tun. Kann mir jemand sagen, was das Problem ist, da ich nicht weiß, wo man suchen? Auch wenn es kein Problem ist, dann weiß jemand, wie es zu deaktivieren, da diese mich daran hindern, immer zu den einzelnen Stützpunkten Ich setzte mich?

Vielen Dank im Voraus!

EDIT: (Hinzufügen der Ausgabe von dem Befehl des GDB): Wo kann ich sehen, was jede dieser Funktionen haben, so kann ich sehen, was ich falsch mache? 

#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 ?? ()
War es hilfreich?

Lösung

Während die Frage ist jetzt schon recht alt ist, sind hier einige Punkte, die jemand helfen könnte, die hier nach einer Suche kommen würde wie ich:

Ich treffe gerade das Problem beim Testen auf Win7 eine App von mir auf WinXP entwickelt. In meinem Fall ist es sowohl für Windows 7 Speicher-Management-Überwachung und eine schlechte Speicherzuweisung in meiner app bezogen.

Die Geschichte kurz zu machen, in dem App-Code, ein Speicherblock, der durch Fehler malloced wurde (anstelle der Verwendung GlobalAlloc()) und wurde mit einem GlobalFree() befreit (das ist falsch, da das System heap mit einem Zeiger von der zugegriffen wurde C-Laufzeitspeicher-Pool). Während dies ein Speicherleck (sehr klein in diesem Fall) verursacht, es war völlig unbemerkt, während auf WinXP Testen und das ganze Programm scheinbar korrekt ausgeführt wurde.

Nun, wenn auf Win7 ausgeführt, eine Speicherüberwachung Funktion namens Fault tolerant Heap (FTH) erkennt diesen Fehler der App (die eine Ausnahme verursacht):

  • Zur gleichen Zeit wird es einige Informationen über OutputDebugString() (oder vielleicht DbgPrint()) ausgibt, das die einfache angezeigt werden kann Debugview Werkzeug oder durch jedes Debuggers, wenn die Anwendung zu verfolgen. So kurz vor dem empfangenen Signal kann man so etwas in den Nachrichten sehen:

      

    Warnung: HEAP [name_of_your.exe]:

         

    Warnung: ungültige Adresse angegeben RtlFreeHeap (006B0000, 006A3698)

  • Und (im Fall der Anwendung gedebuggt wird) gibt er einen Haltepunkt, die keinen Effekt außerhalb eines Debuggers hat, aber das sollte anders helfen, das Problem zu zeigen. Das Breakpoint als SIGTRAP Signal von GDB gezeigt .

An diesem Punkt haben Sie zwei Alternativen:

  • versuchen, den Call-Stack läuft die fehlerhafte Anweisung in Ihrem Code zu finden (leider in diesem Fall können die bt oder where gdb Befehle nicht weit genug zeigen, um zu sehen, wo in meinem Code wurde der Haufen falsch befreit - , wenn jemand statt ntdll weiß, wie der richtigen Call-Stack aus dem Startmodul angezeigt werden, lassen Sie mich wissen, )
  • versuchen, weiterhin als FTH die Fähigkeit hat, automatisch in dem Speicher als ein Versuch, Patch um den Fehler zu arbeiten
    • (die Automagic Patch auch im voraus auf dem nächsten Laufe der App auftreten kann)

Für nicht zum Zeitpunkt des Haufens Problem zu stoppen, wie Moshe Levi sagte: Sie handle SIGTRAP nostop an der GDB Aufforderung festlegen, bevor Sie die App starten.

Also kurz gesagt: ja hast du etwas falsch in Ihrem Code in Bezug auf die Speicherverwaltung, aber in manchen Fällen kann es ohne Absturz führen kann. Aber im Debug-Modus versucht der Kernel Dich auf dem Weg des Problems zu setzen.

Andere Tipps

Wow, Sie schickte mich wieder 5 Jahre, wenn ich verwendet GDB auf der Linux-Plattform:)

Sie können gdb verhindern zu brechen, wenn SIGTRAP mit folgendem Befehl empfangen: 

handle SIGTRAP nostop

Aber ich bin mit steve hier, versuchen Sie WinDbg statt. Es wurde speziell für Fenster gebaut.

würde ich empfehlen WinDBG, die native Windows-Debugger zu verwenden. Dies gibt besseren Stack-Traces vor allem für die Symbole, wenn es Übergänge des Kernelmodus.

ich gerade erlebt diesen Absturz mit gcc / mingw mit Qt Creator.

ich andere Probleme hatte auch einschließlich Variablen, die falsch zu sein schien (Offset von 6 Bytes). In meinem Fall stellte sich heraus, ein Pragma Pack sein, die sich verheerend auf den Code wreaked.

Ich habe dies: 

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

... aber ich wird nicht beenden es mit einem Pragma pack () ruft Verpackung von 1 nach der Struktur zu beenden und auf die Standard Byte-Ausrichtung / Verpackung zurück. Fügte hinzu, dass es fest: 

#pragma pack(1)
typedef struct SomeStruct
{
... // structure
} SomeStruct;
#pragma pack() // <<-- with this line the heap corruption problem was stopped
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top