Andre strategier til debugging af C/C++ kode på Linux?
Jeg sidder og debugger en store klump C/C++ kode på en Linux-maskine - ca. 500.000 linier vel. Jeg er ved at være lidt muggen fordi mine normale debugging-værktøjer ikke giver hjælp om problemet. Lad mig lige forklare lidt mere om hvad jeg normalt laver af ulykker og hvordan jeg finder problemets rod.
Jeg laver en del kode i C/C++ med malloc/new-kode og jeg har en sjat modul-tests, som kører fint. Der er "styr på" at al hukommelse frigives fint efter brug i de tilfælde.
Jeg har nu en segmenteringsfejl, hvor der er nul hjælp til hvor det sker. gdb/ddd har ingen "backtrace" information (kør "bt" efter fejlen sker) og ddd melder endda intern fejl. Jeg har prøvet at indkredse fejlen med
- valgrind/valkyrie - som køre programmet uden ændringer. Langsomt med normalt super godt til at vise allokeringsfejl.
- purify - kommercielt program, som ændrer link-fasen og instrumenterer koden.
- insure++ - kommercielt program, som reelt omskriver koden og så oversætter den. For hver array-adgang indsættes kode som checker at index er lovligt eller ej. Og tilsvarende laves tonsvis af andre godt checks.
Her står jeg med fejl, som ikke findes med nogen af ovenstående. Er der nogle tools, som jeg har overset til "heavy"-debugging?
Jeg er nok ikke interesseret i statisk kode-analyse her - kun dynamisk kodeanalyse.
Jeg er på vej til at rulle tilbage til gode gamle "printf" ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")
Alle kommentarer modtages med stor interesse!
/pto
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
