C/C++ Debugging Strategie

[rubricanis]

Ich bin zum debuggen bislang recht gut damit klar gekommen in die in Frage kommenden Funktionen entsprechende Ausgabefuntionen einzufügen. Da bin ich wie es scheint jetzt an eine Grenze gekommen...

In einem länglichen Testprogramm (wohl > 100 Test-Funktionen) bekomme ich immer mal wieder std::bad_alloc exceptions und ich kann beim besten Willen nicht ausmachen wo die her kommen. Das witzige dabei ist dass sie offenbar bei eigentlich eher trivialen Vergleichsoperatoren ausgeworfen werden bei denen eigentlich keine Allocatoren verwendet werden. Klar, die Ausgabe erfolgt mit std::cout & friends. Insofern könnte das auch ein Seiteneffekt des Testprogrammes sein aber da sind die einzelnen Funktionen auch recht simpel. Auch bei einem noch so tiefen Blick in den Code kann ich nichts problematisches finden.

Wie auch immer: Muss ich mich jetzt auch noch in GDB einarbeiten oder gibt es einfachere Methoden um solchen Fehler a.d. Grund zu kommen ?

Peter

 

[Kamikaze]

Der Debugger ist schon die richtige wahl. Ein Backtrace kann da sehr Aufschlussreich sein.

 

[goblin]

ein backtrace aus gdb zu bekommen ist nicht schwer:

$ ./sf
Segmentation fault
$ gdb ./sf
GNU gdb (Ubuntu 7.9-1ubuntu1) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./sf...done.
(gdb) run
Starting program: /tmp/sf

Program received signal SIGSEGV, Segmentation fault.
0x0000000000400506 in crash () at sf.c:8
8               *p = 7;
(gdb) bt
#0  0x0000000000400506 in crash () at sf.c:8
#1  0x0000000000400517 in main () at sf.c:14
(gdb) frame
#0  0x0000000000400506 in crash () at sf.c:8
8               *p = 7;
(gdb) i local
p = 0x0

(Jaja, Ubuntu, weil ich auf der Arbeit bin…)

bt gibt einen backtrace, mit frame kann man den aktuellen stackframe anzeigen, mit info locals die lokalen Variablen, mit info arg die Argumente, mit select n den n-ten frame auswählen, mit list wird der Kontext angezeigt. Ich glaube ich habe nichts vergessen, das ist so ziemlich alles, was ich mit gdb kann, aber es reicht 98% der Zeit vollkommen aus.

Edit: Ich hab doch was vergessen: print var gibt den Wert der Variablen var aus, mit printf kann man das sogar formatieren.

 

[rubricanis]

Der Debugger ist schon die richtige wahl. Ein Backtrace kann da sehr Aufschlussreich sein.

Ich habe es befürchtet! Das Programm ist ja ein Monster! Aber ...

ein backtrace aus gdb zu bekommen ist nicht schwer: ...

... Problem gelöst!

Ein wirklich blöder Fehler! Ich hatte bei einem "byte* vec = new byte[sz + space];" die Berechnung des Space hinter dem new. Da ist wohl irgendwann beim kopieren von text mal etwas durcheinander geraten und schon war der Kladderatsch da und hat mir andere Variable überschrieben.

Ich bedanke mich bei euch beiden!

Peter -- as blind as men can be!