Beste manier om geheugencorruptie te debuggen met gdb

[KillerSponge]

Ik ben al een tijdje bezig met een (voor mij) iets groter project gebaseerd op SDL onder Ubuntu. Sinds een paar dagen krijg ik nu af en toe (dus lang niet altijd) tijdens het opstarten segfaults, en tijdens het afsluiten soms memory corruption (libc melding over 'double free or corruption'). Als een vriend van mij exact hetzelfde programma draait, krijg hij deze foutmeldingen niet. Als ik bepaalde arbitraire delen van het programma aan- of uit zet heb ik ook nergens last van.

Stacktraces van deze crashes in gdb geven bij de segfault een trace naar een intern SDL proces voor event handling (waar ik dus verder niks mee te maken heb volgens mij), en bij de memory corruption krijg ik alleen een lijst met (??) locaties te zien. Dit lijkt er op te wijzen dat ik ergens heel veel geheugen overschrijf, maar waar?

Mijn vraag is dan ook vooral: hoe ga ik in dit soort gevallen te werk, waar begin ik als ik geen idee heb in welk deel van de code de fout zit?

Wat ik dus al geprobeerd heb:
- Backtrace met gdb (levert niks op, want in het ene geval komt het nooit in mijn code uit, en in het andere geval is de trace al overschreven)
- Delen van het programma uitschakelen (het probleem hierbij is dat het niet echt uitmaakt welke delen van het programma ik uitzet, en gezien het probleem maar heel sporadisch voorkomt weet ik zo nooit zeker waar het probleem precies zit)

[HMS]

Misschien kan Valgrind hier bij helpen? http://valgrind.org/

[farlane]

Eerste ingeving : check je arrays en pointers op off by one fouten, valgrind zou je daarbij idd kunnen helpen.

Het type bug dat je hebt heeft trouwens ook een naam : Heisenbug

[Soultaker]

Om te beginnen: compileren zonder optimalisaties (-O0) en mét debuginformatie (-g) en dan hopen dat de bug niet verdwijnt. Dan krijg je sowieso een stuk zinnigere core dumps.

Verder is Valgrind inderdaad een goede tool om geheugenfouten te vinden nog vóór ze problemen veroorzaken. Let wel dat ook Valgrind false positives kan geven. Het is vaak lastig te zien of een fout in bijvoorbeeld SDL of een videodriver wel of niet (indirect) door jou veroorzaakt is. Maar het is een poging waard.

[KillerSponge]

Bedankt voor alle tips, ik heb eindelijk de tijd gehad om me in valgrind te verdiepen, en na wat knoeien is het probleem opgelost. Super bedankt! Onmisbare tool

[Matis]

Valgrind is inderdaad een goede tip. Kijk daarnaast eens naar static source code checkers: Wikipedia: List of tools for static code analysis
Wij hebben zakelijk flexelint (betaald) in gebruik, maar ik heb privé veel positieve ervaringen met splint.
Met bovenstaande tools heb ik al veel mogelijke race condities blootgelegd.