testo schrieb:
Hallo,
ich habe schon einiges gelesen was debugging angeht aber komme nicht auf den grünen zweig...
ich würde gerne wissen wie Ihr das so handhabt mit dem debuggen bzw. wie es wirklich sein sollte als wie man es üblich macht.
Ich erläre mal wie ich das bisher gemacht habe und ich glaube dass das ziemlich schlecht war meine Methodik:
Ich habe bisher immer mit IDE's gearbeitet unter LInux und jetzt schreibe ich gerade ohne IDE in der Konsole was erstaunlicherweise ganz gut läuft. Meine Projekte umfassen < 10000 Zeilen.
Meine Erfahrung mit den IDE-gesteuerten Debuggern ist die, dass man diverse Breakpoints ausprobiert und es dann irgendwo knallt und ich es nicht verstehe. Irgendwann lässt ich die Breakpoints dann ganz weg, um den Ablauf wirklich nachzuvollziehen, so dass ich bei echten Problemen durch etwa 25 Rekursionsstufen unterschiedlichster Klassen marschiere, dafür 30 Minuten brauche und plötzlich knallt's und ich weiß immernoch nicht warum.
Ich klicke dann man nur noch auf 'weiter', 'weiter', 'weiter', BUMM, 'weiter', 'weiter', ?, 'weiter'... Mist... verpasst...
Dann weiß man zwar wo es geknallt hat, aber das wußte man idR vorher auch schon.
testo schrieb:
Bisher habe ich immer mit Ausgaben gearbeitet. Also einfach wenn was nicht geklappt hat arrays oder sonstiges einfach ausgeben und überprüfen.
Wenn dann mal ein seg-fault kam habe ich auskommentiert und so lange ausgaben hin und her geschoben bis ich den bug lokalisiert habe.
Das ist eher eine Notlösung - die im Notfall allerdings auch helfen kann. Oder das Problem so verkompliziert, dass auch nicht weiterkommt - man kann schließlich nicht Vorbedingungen auskommentieren, weil das Programm sonst aus anderen Gründen, wie falschen Initialisierungen o.ä. aussteigt.
Debuggen bedeutet sehr mißtrauisch zu sein. Warum kann ein Fehler auftreten (das sind häufig Erfahrungswerte), wenn dieser Fehler auftritt, musst Du klären, wie die Eingangswerte sind (also ausgeben) und prüfen, ob die Eingangswerte Deinen Erwartungen entsprechen oder ob der Fehler eigentlich schon viel früher passiert ist.
Ich habe meine Fehler immer debuggt. Fehlerhaften Source sollte man in zeitkritischen Situationen neu schreiben, aber später trotzdem debuggen, um die Erfahrung zu bekommen. Mein Highlight sind 8 Wochen Debuggen, um einen kleinen Fehler zu finden, den ich mir durch's debuggen entfernt habe. Lief das Programm im Debug-Modus war alles okay, ohne Debuginformationen auszugeben, schmierte es ab. Die Erfahrung ist viel wert.
Mit printf debugge ich eigentlich sehr schnell, schneller als mit allen anderen Tools.
Man muss lernen die richtigen Fragen zu stellen.
Um Fragen zu stellen, lasse ich Programme auch gerne an interessanten Stellen absichtlich abschmieren, um z.B. mit dem gdb die Werte der einzelnen in den einzelnen Funktionsaufrufen zu verfolgen.
testo schrieb:
Den Debugger habe ich selten angeworfen weil ich mit den debuggern nicht so zurecht komme (noch). Jetzt müsste ich den gdb in der Konsole bedienen der nicht ganz intuitiv ist.
Wie macht ihr das so?
Der gdb ist auf der Konsole sehr umständlich, aber die wichtigen Dinge sind eigentlich nur "backtrace", "frame" und "print". Mehr braucht man eigentlich kaum.
Gelegentlich zerschlägt man sich den Stack, woraufhin "backtrace" nicht mehr funktioniert. Ist der Stack weg, nicht verzweifeln, das ist ein gutes Indiz, dem Fehler auf der Spur zu sein: Du schreibst in Speicherbereiche, in denen Du nichts zu suchen hast. Bleibt die Frage wo und wann.
Hier kann das Tool valgrind sehr hilfreich sein, es überwacht ob Speicherzugriffe in gültige Bereiche stattfinden. Allgemein sollte man sein Programm immer mal wieder durch valgrind ausführen lassen, weil man damit gut Fehler und Anregungen findet, die bei den gewählten Tests nicht auffällig wurden, z.B. delete statt delete[].
Die zwei Tools und printf um Fragen zu beantworten und meinen Kopf, um Fragen zu stellen. Viel mehr brauche ich eigentlich nicht zum Debuggen.
