[C++] Programmacrash info

[Verwijderd]

Hello,

Hier ben ik alweer eens met een vraag: momenteel werk ik aan een redelijk groot programmeerproject, waarin debugging redelijk veel tijd kost door de grote hoop code (bijna 20k lijnen). Hierdoor heb ik een soort crashdetectie ingebouwd dmv 'try' en 'catch' statements en krijg ik er iets meer vat op. Wat ik wil is meer details over de crash zelf, bijvoorbeeld de naam van functie (eventueel van een bepaalde klasse) die crasht. Wat ik momenteel deed is een soort van programma status bijhouden dat aan het begin van elke functie op een bepaalde status wordt gezet (die gelijk staat aan die functie) en aan het einde van de functie wordt die status op 'unknown' gezet.
Die statusinfo wordt dan gebruikt bij de crashinformatie als het programma crasht, zodat de gebruiker sneller de fout kan vinden en kan debuggen. De states zijn gedifinieerd als integer.

Iets zoals dit:

code:

void Init()
{
    state(STATE_INIT);
    // code
    state(STATE_UNKNOWN);
}

Is dit een effectieve manier? Of zouden jullie iets anders aanraden?

Greetz,
Ken

[.oisyn]

Als in, crash info voor release mode zodat je crashes bij andere mensen kunt onderzoeken?

Ik zou een stackdump genereren. Een try/catch is niet fijn want dat geeft je geen info over de crash zelf. En idd, dan moet je dus dat soort kapriolen uithalen om uit te vinden waar de crash nou ontstaan is.

Beter kun je gewoon een eigen structured exception handler zetten. In VC++ is het zelfs zo dat normale C++ exceptions ook via die handler gaan (is wel undocumented, courtesy of curry684 ). In die handler zou je een stack dump kunnen schrijven naar een file, en het programma op een nette manier kunnen afsluiten met een bericht naar de gebruiker toe.

Check de structured exception handling topics in de MSDN, en als je VC++ gebruikt _set_se_translator


^{(en ik hoef je toch niet meer te vertellen dat groeten onder je post niet hoeft op GoT, of wel? )}

[ Voor 8% gewijzigd door .oisyn op 13-09-2003 23:32 ]

[Soultaker]

Als je echt C++ exceptions gebruikt, kun je het beste de exceptions die je niet kunt afhandelen ook niet catchen! Je krijgt dan voor elke onafgehandelde exception een nette core dump, waarmee je vervolgens uit kunt zoeken waar de exception precies vandaan kwam en wat de interne staat van het programma toen was.

Verder lijkt me dat je huidige manier van debuggen (die wel tijdelijk geschikt is voor kleine stukken code, maar me niet praktisch lijkt voor het permanent beschermen van grote hoeveelheden coden) me nogal slecht werken in combinatie met genste functie-aanroepen.

offtopic:
Ik vind 20k regels code trouwens niet zo schokkend veel.

Hmz, als ik het eens vergelijk met m'n eigen projectjes is het toch wel veel. Dat is meestal per op-zichzelf-staand component beperkt tot iets van 20 source files van rond de 250 regels per stuk, dus dat is inclusief header files hooguit iets van 7000 regels.

[ Voor 18% gewijzigd door Soultaker op 13-09-2003 23:37 ]

[.oisyn]

Soultaker schreef op 13 september 2003 @ 23:33:
Als je echt C++ exceptions gebruikt, kun je het beste de exceptions die je niet kunt afhandelen ook niet catchen! Je krijgt dan voor elke onafgehandelde exception een nette core dump, waarmee je vervolgens uit kunt zoeken waar de exception precies vandaan kwam en wat de interne staat van het programma toen was.

een uncaught c++ exception geeft je niet standaard zomaar een core dump. Niet onder win32 iig, maar misschien moet de TS eens platform/compiler erbij zetten

[Soultaker]

.oisyn schreef op 13 September 2003 @ 23:51:
een uncaught c++ exception geeft je niet standaard zomaar een core dump. Niet onder win32 iig, maar misschien moet de TS eens platform/compiler erbij zetten

Hmz, ik krijg onder Windows wel zo'n "Do you want to debug?"-dialog, waarna ik in Visual Studio de call stack enzo kan bekijken (wat de TS geloof ik wilde). Er wordt dan inderdaad niet echt een core dump naar de harde schijf geschreven en het werkt dus alleen als je zelf op de machine zit te ontwikkelen waarop je je applicatie draait (wat een gewone gebruiker heeft natuurlijk geen Visual Studio geinstalleerd).

[MSalters]

De "Core dumper"van Windows kaal was toch Dr. Watson. Wat is daar mee gebeurt?
In elk geval kun je een van de vele JIT debuggers installeren. Een JIT debugger wordt pas bij een uncaught exception geladen. Zo zou je bijvoorbeeld "Debugging Tools for Windows"aka windbg kunnne installeren op non-develop test PCs.

[.oisyn]

damn, ik ging eens zoeken in de MSDN naar dr. watson, kwam ik deze functie tegen:
MiniDumpWriteDump (is onderdeel van de DbgHelp API). Wist helemaal niet dat die bestond
En blijkbaar kun je die files ook gewoon openen in de VC++ debugger.

Dus je bouwt (met VC++ iig) gewoon een SE translator die een minidump naar een file schrijft, et voila

.edit: oh damn, het is vanaf XP en Server 2003
.edit2: nee wacht, voor de rest is er DbgHelp.dll als redistributable

.edit3: heb het even geprobeerd, werkt echt fantastisch
Die dump files kun je weer openen in VC++, en je krijgt gewoon de debugger met als context het moment dat de dump gegenereerd is.
Er zit alleen wel een quirck in: de stackdump van de thread die de minidump genereerde is niet juist, dus je moet de stackdump door een andere thread laten doen

[ Voor 45% gewijzigd door .oisyn op 14-09-2003 02:55 ]

[Verwijderd]

.oisyn schreef op 13 September 2003 @ 23:31:
Als in, crash info voor release mode zodat je crashes bij andere mensen kunt onderzoeken?

Ik zou een stackdump genereren. Een try/catch is niet fijn want dat geeft je geen info over de crash zelf. En idd, dan moet je dus dat soort kapriolen uithalen om uit te vinden waar de crash nou ontstaan is.

Beter kun je gewoon een eigen structured exception handler zetten. In VC++ is het zelfs zo dat normale C++ exceptions ook via die handler gaan (is wel undocumented, courtesy of curry684 ). In die handler zou je een stack dump kunnen schrijven naar een file, en het programma op een nette manier kunnen afsluiten met een bericht naar de gebruiker toe.

Check de structured exception handling topics in de MSDN, en als je VC++ gebruikt _set_se_translator


^{(en ik hoef je toch niet meer te vertellen dat groeten onder je post niet hoeft op GoT, of wel? )}

Kvoel me noob want ik ken niks van stackdumps oid (mss versta ik het onder andere terminologie, maar kdenk dat ik gewoon noob ben ).
Ik werk iig niet met VC++, maar met een gnu mingw compiler. Ik zoek wel wat info op over stackdumps.

Wat ik ook bvb niet van plan ben is debuginfo in m'n game zelf te plaatsen, omdat het dan makkelijker is om cheat patches te maken (vermits het een spel wordt)
Thx vr je reply

@Soultaker:
Bijna alle (std library) c++ exceptions zijn ge'catch'ed, maar ze geven niet allemaal (nog niet) gedetailleerde info

[ Voor 5% gewijzigd door Verwijderd op 15-09-2003 20:45 ]

[.oisyn]

Dump files kun je ook openen in windbg, die je gratis kunt downloaden.

Aan een stack trace kun je zien hoe je functies genest zijn. Als je bijvoorbeeld vanuit je main een functie aanroept, en vandaar uit weer een andere functie, dan zie je dat ook zo in je stack trace staan.
Debug info meeleveren is niet nodig. In win32 executables zit debug info sowieso nooit in je executables zelf, maar in aparte program databases. Ik weet overigens niet hoe mingw gcc dat doet.

[Verwijderd]

.oisyn schreef op 15 september 2003 @ 21:06:
Dump files kun je ook openen in windbg, die je gratis kunt downloaden.

Aan een stack trace kun je zien hoe je functies genest zijn. Als je bijvoorbeeld vanuit je main een functie aanroept, en vandaar uit weer een andere functie, dan zie je dat ook zo in je stack trace staan.
Debug info meeleveren is niet nodig. In win32 executables zit debug info sowieso nooit in je executables zelf, maar in aparte program databases. Ik weet overigens niet hoe mingw gcc dat doet.

Thanks, nu snap ik het Kga er zo snel mogelijk meer info omtrent opzoeken. Het lijkt me een beetje op het systeem van code profiling, maar dan met andere doeleinden.

[Verwijderd]

maar als je code op de juiste plekken voorzien is van assert's enzo weet je toch zowieso wanneer er iets fout gaat (en waar) ?

(Er vanuit gaande dat je gewoon in debug-mode test)

[.oisyn]

Best knap als het je zelf lukt om alle bugs te ontdekken

en ook met een assert kun je niet alles afvangen. Wat als je bijvoorbeeld een pointer naar een stukje geheugen hebt dat je al hebt vrijgegeven?

[Verwijderd]

dan crasht ie in de functie waar je die gebruikt, en weet je dus precies waar het is fout gegaan (als je in debug-mode runt ).

Maar call-stack tracen is tuurlijk altijd goed.

Zie bv. http://www.ddj.com/documents/s%3D1642/ddj0302c/

[farlane]

Verwijderd schreef op 16 september 2003 @ 15:11:
dan crasht ie in de functie waar je die gebruikt, en weet je dus precies waar het is fout gegaan (als je in debug-mode runt ).

Hmm, ik denk dat jij nog nooit een stacksmash hebt moeten opsporen. Hiermee kun je makkelijk variabelen trashen die je op een compleet andere plaats gebruikt worden, en dus de fout op een compleet andere plaats optreedt.( 1 keer per week ofzo )

[Verwijderd]

Die url ziet er interessant uit en 't geeft een duidelijker beeld voor me wat een stack trace precies is.
Ik denk alleen dat het te gevoelige info vrijgeeft aan hackers die cheat patches willen maken voor de toepassing van dit soort technieken in een spel. Of begrijp ik dat verkeerd?

[madwizard]

Je kan ook altijd een mapfile genereren voor de release, die file voor jezelf bewaren en als je een bug report krijgt met het crashadres en/of callstack kun je in de mapfile opzoeken waar die adressen in vallen. Je kan waarschijnlijk ook wel een release versie met debug info maken maar zorg wel dat de optimalisatieopties enzo hetzelfde zijn anders wijzigt je code en dus de addressen ook. Een normale debug build heeft minder geoptimaliseerde code om zo het debuggen beter mogelijk te maken (stap voor stap doorlopen kan vaak niet in release mode code).