c ++ - debug stack overflow i windows?

Indlæg af Hanne Mølgaard Plasc

Problem



Så jeg forsøger at debug dette mærkelige problem, hvor en proces slutter uden at kalde nogle destruktorer ...


I VS (2005) debuggeren rammer jeg 'Break all' og kigger rundt i opkaldsstablerne af tråderne i den mystisk forsvindende proces, når jeg ser dette:


lugt som sådan http://img6.imageshack.us/img6/7628/95434880.jpg[5]


Det ser helt sikkert ud som en så ved at gøre, hvilket ville forklare, hvorfor processen løber til sit lykkelige sted uden at pakke sin kuffert først.


Problemet er, at VS debuggerens call stack kun viser, hvad du kan se i billedet.


Så mit spørgsmål er: Hvordan kan jeg finde, hvor det uendelige rekursionsopkald starter?


Jeg læste et sted, at i Linux kan du vedhæfte tilbagekald til SIGSEGV-handleren og få mere information om, hvad der foregår.


Er der noget lignende på Windows?

Bedste reference


For at kontrollere, hvad Windows gør i tilfælde af adgangsbrud (SIGSEGV - tilsvarende), ring SetErrorMode (send det parameter 0 for at tvinge en popup i tilfælde af fejl, så du at vedhæfte det med en debugger.) [7]


Baseret på den stablingsspor, du allerede har opnået, kan vedhæftning med en debugger på fejl muligvis ikke give yderligere oplysninger . Enten er din stak blevet beskadiget, eller dybden af ​​rekursion har overskredet det maksimale antal rammer, der kan vises af VS. I det sidstnævnte tilfælde vil du måske reducere procesens standardstakstørrelse (brug /F -knappen eller tilsvarende indstillingen i Projektegenskaberne) i rækkefølge for at få problemet til at manifestere sig tidligere, og sørg for, at VS vil vise alle rammer. Du kan alternativt holde et breakpoint i std :: basic\_filebuf <> :: flush () og gå gennem det indtil ødelæggelsesfasen (eller deaktivere det, lige før ødelæggelsesfasen.)

Andre referencer 1


Nå ved du, hvilken tråd problemet er på - det kan være et simpelt spørgsmål om at spore igennem det fra begyndelsen for at se, hvor det går ud i ukrudtet.


En anden mulighed er at bruge en af ​​debuggerne i Debugging Tools for Windows-pakken - de kan muligvis vise mere end VS debugger (måske), selvom de generelt er mere komplekse og vanskelige at bruge (faktisk måske på grund af det) . [8]

Andre referencer 2


Det ser på første øjekast som en uendelig rekursion, man kan forsøge at sætte et breakpoint på linjen før den, der afslutter processen. Går det der ok? Hvis det gør, har du to ret nemme måder at gå på.


Enten går du bare fremad og se hvilke destruktorer der bliver kaldt, og når det bliver fanget. Eller du kan sætte en printf/OutputDebugString i alle relevante objekter destructor (Kun dem, der er globals, skulle have brug for dette). Hvis meddelelsen er den første ting destruktoren gør, så er den sidste besked, du ser, fra destructoren, der hænger op.


På den anden side, hvis det ikke kommer til det brudpunkt, jeg oprindeligt nævnte, kan jeg gøre noget lignende, men det vil være mere irriterende, da programmet stadig er 'at lave ting'.

Andre referencer 3


Jeg ville ikke udelukke at der var sådan en håndterer i Windows, men jeg har aldrig hørt om det.


Jeg tror, ​​at det spor, du viser, kan være falsk. Hvis du brød ind i processen efter en form for korruption allerede havde fundet sted, er sporingen ikke nødvendigvis gyldig. Men hvis du er heldig, har bunden af ​​stakken sporet stadig nogle spor om, hvad der foregår.


Prøv at sætte Sleep() opkald i udvalgte funktioner i din kilde, der kan være involveret i rekursionen. Det burde give dig en bedre chance for at bryde ind i processen, før stakken er helt overflødig.

Andre referencer 4


Jeg er enig med Dan Breslau. Din stak er falsk. kan simpelthen fordi du ikke har de rigtige symboler.
Hvis et program simpelthen forsvinder uden at WER-håndteringen går i gang, er det som regel ude af hukommelse. Har du gået undersøgt denne mulighed?