Haltepunkte aus dem nichts beim Debuggen mit gdb, innen ntdll

Ich ein sehr einfaches Programm, das automatisiert, einige Dinge für mich.Ich schrieb es in c++ und läuft unter Windows. Beim Debuggen mit GDB von innerhalb des Codeblocks IDE , bekomme ich viele Haltepunkte aus dem nichts. Ich habe keine Idee, was wäre dieses problem verursachen. Die Haltepunkte zu sein scheinen im Zusammenhang mit Speicher Probleme ... seit Wann ich reparierte ein Speicherleck hatte ich erkannt, die Haltepunkte Anzahl bekam deutlich weniger.

Die genaue Sache, dass der gdb sagt mir:

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

Bekomme ich diese viele, viele Male in meinem Programm. Ich denke, dass ich vielleicht etwas sehr falsch, obwohl das Programm scheint zu laufen just fine, und es leistet, was ich will, es zu tun. Kann mir jemand sagen, was das problem da ich nicht weiß, wo zu suchen? Auch wenn es kein problem ist, dann weiß jemand, wie man deaktivieren, da dies verhindert, dass mir immer zu den breakpoints, die ich mir gesetzt habe?

Vielen Dank im Voraus!

EDIT: (durch Hinzufügen der Ausgabe von GDB-Befehl "where"):
Wo kann ich prüfen, was diese Funktionen tun, 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 ?? ()
Was macht der rest von call-stack Aussehen, wenn Sie ein SIGTRAP? Poste bitte die Ausgabe von GDB "where" - Befehl.
Danke für Eure Antworten, ich werde hängen Sie die Ausgabe des "wo" in der Frage. Bearbeiten Sie jetzt...

InformationsquelleAutor Lefteris | 2009-10-25

  1. 16

    Während die Frage ist sehr alt nun, hier sind einige Punkte, die helfen könnten, dass jemand kommen würde, hier nach einer Suche, wie ich getan habe:

    Ich habe gerade festgestellt, dass problem während des Tests auf Win7 eine app entwickelt, die von mir auf WinXP. In meinem Fall ist es sowohl für Windows 7-Speicher-management-überwachung und ein bad memory allocation in meiner app.

    Um es kurz zu machen, in der app-code, ein Speicher-block, der war malloced durch Fehler (anstatt GlobalAlloc()) und befreit wurde, mit einem GlobalFree() (ist falsch, da das system heap zugegriffen wurde mit einem Zeiger aus der C-runtime-Speicher-pool). Während dies verursacht einen (sehr kleinen, in diesem Fall) memory leak, war es völlig unbemerkt während des Tests auf WinXP und das ganze Programm läuft scheinbar korrekt.

    Nun auch ausgeführt, wenn auf Win7, ein Speicher-monitoring-Funktion genannt Fault Tolerant Heap (FTH) erkennt diese Fehler in der app (das verursacht eine exception) :

    • Zur gleichen Zeit ist es die Ausgabe einige Infos über OutputDebugString() (oder vielleicht DbgPrint()) , können eingesehen werden mit der einfachen DebugView tool oder von einem debugger bei der Verfolgung der Anwendung. So kurz vor den empfangenen Signals können Sie sehen, daß soetwas in den Nachrichten :

      warning: HEAP[name_of_your.exe]:

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

    • Und (in dem Fall die app ist gedebuggt wird) gibt es einen Haltepunkt, der hat keinen Effekt außerhalb eines Debuggers, aber anderes, das sollte helfen um das problem. , Der Haltepunkt wird gezeigt, wie die SIGTRAP-signal von GDB.

    An dieser Stelle haben Sie 2 alternativen :

    • versuchen Sie zu Fuß den call-stack zu finden, die fehlerhafte Anweisung in deinem code (leider in diesem Fall, die bt oder where gdb-Befehle nicht zeigen kann, weit genug, um zu sehen, wo in meinem code der Haufen wurde zu Unrecht befreit - wenn jemand weiß, wie zum anzeigen der richtigen call-stack vom Ausgangs-Modul statt ntdll, lassen Sie mich wissen,)
    • versuchen Sie weiterhin als FÜNFTES hat die Fähigkeit, automatisch patch im Speicher als ein Versuch zu arbeiten, um Ihre Fehler (automagic patch kann auch auftreten, im Voraus auf die nächsten ausführen der app)

    Nicht zu stoppen in der Zeit der heap-problem, wie Moshe Levi sagte, man kann einen handle SIGTRAP nostop bei der GDB Eingabeaufforderung vor dem starten der app.

    Also kurz : ja du hast etwas falsch in Ihrem code relativ zum Speicher-management, aber in einigen Fällen kann es laufen, ohne abzustürzen. Aber im debug-Modus den kernel versucht, Sie auf den Pfad des Problems.

    Ich möchte hinzufügen, dass sieht nicht immer der code falsch ist. Ich bin ziemlich gleich problem, und eine Warnung Heap block at 003E5E78 modified at 003E5EBA past requested size of 3a. Ich bin sogar erwischt, am falschen Ort, löst die Warnung, und der code sieht gut aus: ich erstellte «wchar_t» - Reihe mit «neuen» und die nächste freie es mit «delete[]». Wahrscheinlich ein Fehler in MinGW. Btw, eine Sache, die indirekt bestätigt: ich bin testen der Anwendung unter GNU/Linux mit valgrind, und es nicht bemerkt, keine Probleme.

    InformationsquelleAutor

  2. 7

    Wow, Sie schickte mich wieder 5 Jahre um, wenn ich den gdb auf den linux-Plattform 🙂

    können Sie verhindern, dass der gdb zu brechen, beim Empfang SIGTRAP mit dem folgenden Befehl:

    handle SIGTRAP nostop

    Aber ich bin mit steve hier, Probieren Sie WinDbg statt. Es wurde speziell für windows.

    Wo Sie annehmen, man könnte sich eine freie WinDbg? AFAIK ist gebracht nur mit Visual Studio, ich bezweifle, dass jemand gonna kaufen, nur weil der ein debugger, der auch nicht besser gdb. Aber ⁺1 eh: ich bin mir gar nicht aufgefallen, dass die Haltepunkte in system-Bibliotheken verursacht ein weiteres signal, die andere aus einer üblichen Pause.
    WinDbg ist kostenlos und kommt als Teil der Debugging Tools für Windows-Paket. Den download finden Sie microsoft.com/click/services/Redirect2.ashx?CR_EAC=300135395

    InformationsquelleAutor

  3. 2

    Ich würde empfehlen die Verwendung von WinDBG, die native windows-debugger. Dies wird zu besseren stack-traces besonders für die Symbole, wenn es übergänge in den Kernelmodus.

    InformationsquelleAutor

  4. 1

    Ich nur erlebt, dieser Absturz mit gcc/mingw mit Qt Creator.

    Hatte ich andere Probleme, einschließlich der Variablen, die schien falsch zu sein (offset 6 Byte).
    In meinem Fall, es stellte sich heraus, dass ein pragma pack, das verheerend auf die code.

    Hatte ich dieses:

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

    ... aber ich wollte nicht kündigen, es mit einem pragma pack () - Aufruf zu Ende der Verpackung 1. nach der Struktur und zu den Standardeinstellungen zurückkehren byte-Ausrichtung/Verpackung. Hinzufügen, dass es fest:

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

    InformationsquelleAutor

Schreibe einen Kommentar