Dette indlæg er alene udtryk for skribentens egen holdning.

Andre strategier til debugging af C/C++ kode på Linux?

18. april 2010 kl. 14:1727
Artiklen er ældre end 30 dage

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=")

Artiklen fortsætter efter annoncen

Alle kommentarer modtages med stor interesse!

/pto

27 kommentarer.  Hop til debatten
Denne artikel er gratis...

...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.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
1
18. april 2010 kl. 16:15

Bruger du fork eller lignende som kan forvirre gdb?

gdb burde altså kunne fortælle dig hvor i memory segfault'en sker.

2
18. april 2010 kl. 20:02

Nej - der er ikke forks i min kode. Jeg har nu fået gdb til at fortælle om en fejl i 0x090c140e in colon_greater () at ...build-gcc-4.2.4/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_iterator.h:652

... og ingen oplagt kobling til min egen kode.