C code für Debugzwecke präparieren(gelöst)

[Anonymous]

Fakten:
# kleines OS Projekt ; C ; ca. 5000 Zeilen,
# Konsoltool derzeit ca. 20 Optionen auf der Kommandozeile
# komplizierter mehrfach verschachtelter Lösungsalgorithmus mit extrem vielen Verzweigungen
# teilweise Grenzbereich zwischen Logik und Heuristrik
# Software bearbeitet normalerweise Rohdaten in GB -> TB Bereich
# Rohdaten müssen nicht (können gar nicht immer) konsistent und schlüssig sein
# Software ignoriert stillschweigend intern die Fehler der Rohdaten
# derzeitiger Status Alpha
# Entwicklertests, Installtionstests, Funktionstests sind soweit ok
# meine derzeitige Einschätzung: robust, volle Funktion, gute Ergebnisse, nur "la-la" Userfreundlich
# noch einige "Schönheitsfehler" bekannt
# zZ entsteht eine umfangreiche deutsche Doku und Gebrauchsanweisung (wer die ins engeldeutsch übersetzen will :???: )
# erstes derartiges Projekt von robi, und der hat von Programmentwicklung eigentlich gar keine Ahnung


Folgendes Problem:
Igendwie muss ich für das Beta Stadium in die Software Debugfunktionen einbauen, vorbereiten was auch immer, die Otto der Normaluser dann aktivieren müsste, wenn er einen Problem mit der Software hat. Welche Möglichkeiten für einen User gäbe es, um Debuginfos zur Verfügung zu stellen, die mir gerade nicht einfallen. Die Rohdaten fallen definitiv aus.

Bei strace währe eventuell alles da, müsste allerdings massiv gezielt und individuell gefiltert werden, :???: :???: :???:
Alles Andere wird wahrscheinlich auch nicht gerade klein ausfallen, wenn ich global für das ganze Programm einen Debuglevel einschalten müsste. Selbst wenn ich mir auch nur von jeder 10. Programmverzweigung ein einzelnes Wort ausgeben lassen würde, bin ich nicht sicher, ob der User das Problem mit seinen Daten sowie mit Programmoptionen soweit einschachteln wird, das es klein genug ist, um per EMail Anhang transportiert zu werden.

Was kann/darf ich Otto dem Normaluser jetzt überhaupt zumuten? Ich bin zur Weiter- und Fertigentwicklung auf möglichst viele gute Fehler-Informationen angewiesen, da es kein Programm für den alltäglichen Gebrauch wird, wird es wohl keine große Testgemeinde finden. Was ist praktisch, was funktioniert in der Praxis, was nicht?

./configure --enable-debug .........
patch -p 0 < debugpatchfile .......
program -debug ............ #fällt wahrscheinlich aus wegen Performanceproblemen

oder fällt euch noch was besseres ein, wie man Debuginfos bei Bedarf erzeugen kann. Hat jemand Erfahrung mit sowas ?

robi

 

[abgdf]

Speicherzugriffsfehler

:mrgreen:

SCNR. Nee, viel Erfahrung habe ich da leider nicht.
Hab' nur mal prinzipiell in den Quellen von xvoice gesehen, daß da manchmal

#define DEBUG = 1

steht und dann im weiteren

#ifdef DEBUG ...

Vielleicht ein Ansatz, um überhaupt einen Debug-Mode sauber in den Code zu integrieren.

Gruß

P.S.: Ansonsten wird der Quelltext ja mit

gcc -g

mit in die ausführbare Datei eingebunden (wenn ich das richtig verstanden habe), so daß man dann mit "gdb" oder "kdbg" ans "echte" Debuggen gehen kann. Da kann man dann Haltepunkte setzen und sich dann den Wert der Variablen zu diesem Zeitpunkt im Code anschauen. Denke aber mal, das weißt Du schon ...
Außerdem zitiere ich zum Debuggen immer ganz gern Kernighan (das "k" in "awk"):

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

:mrgreen:
Aber bitte nicht falsch verstehen: Damit meine ich jetzt nicht Dich, sondern daß man oft am Debuggen von C-Code scheitert. Ich jedenfalls tue das eigentlich immer.

PPS.: Vielleicht meinst Du auch etwas anderes? Nämlich, daß das Programm zwar fehlerfrei läuft, aber die Rohdaten keine saubere Verarbeitung zulassen?
Das wäre dann ja keine Frage des Debuggens ...

 

[Anonymous]

Speicherzugriffsfehler

ich hoffe da bin ich mittlerweile schon ein ganz gut dabei die letzten 4 Wochen keiner mehr

gesehen, daß da manchmal

#define DEBUG = 1

steht und dann im weiteren

#ifdef DEBUG ...

Vielleicht ein Ansatz, um überhaupt einen Debug-Mode sauber in den Code zu integrieren.

das ist schon klar, praktiziere ich ja beim schreiben selbst schon um zu sehen ob gemacht wird was ich will. Aber das an 20 bis 30 Schlüsselpositionen im Programm global zu machen schlägt bei der Schleifen- und Rekursionsflut im Programm ganz gut zu Buche.

mit Einzelpatches die dann entsprechend nur jeweils einzelne bestimmte Stellen genauer untersuchen, tritt das Problem auf, das ich bei jeder gößeren Änderung am Code die Patches wieder neu prüfen muss, eventuell auch neu erstellen damit sie wieder funktionieren. Das ist solange ok wie der User von CVS läd, will er aber nicht er will am liebsten fertige Downloads. Ob das praktikabel ist ?

Ansonsten wird der Quelltext ja mit

gcc -g

mit in die ausführbare Datei eingebunden (wenn ich das richtig verstanden habe), so daß man dann mit "gdb" oder "kdbg" ans "echte" Debuggen gehen kann. Da kann man dann Haltepunkte setzen und sich dann den Wert der Variablen zu diesem Zeitpunkt im Code anschauen.

ich hab das mittlerweile voll drauf , kannst du mir nach 4 Monaten extensive Erfahrungen mit valgrind und gdb ruig mal so glauben. ist aber für den User im Fehlerfall nicht machbar und ich kann es nicht nachvollziehen weil ich die Daten nicht habe die beim User zum Fehler geführt haben.

Das Problem ist, wie soll ich das erklären ????

PPS.: Vielleicht meinst Du auch etwas anderes? Nämlich, daß das Programm zwar fehlerfrei läuft, aber die Rohdaten keine saubere Verarbeitung zulassen?
Das wäre dann ja keine Frage des Debuggens ...

so in etwa.

schau mal in deine PN ich schick dir mal nen Link, für alle Anderen noch etwas gedulden, wenn ich soweit bin euch eine Version anzubieten kann bei der ich euch bei Problemen auch wirklich weiterhelfen kann, bekommt ihr alle eine persönliche Einladung zum Betatest


robi

 

[framp]

Ich würde eine static Variable definieren und zur Laufzeit darauf prüfen. Dann kannst Du im main den debug mode sehr einfach einschalten. Mit der #ifdef Anweisung müßtest Du zwei CodeStände erzeugen - eine mit und ein ohne debug Möglichkeit. Mit der static sind beide Möglichkeiten in einem Executable.

 

[Anonymous]

Ich würde eine static Variable definieren und zur Laufzeit darauf prüfen.

Hatte ich getestet, war aber irgendwie nicht ganz glücklich damit, macht den Quellcode unübersichtlich da die normale Fehler und Ausnahmebehandlung optisch nicht sofort von der Debugbehandlung zu unterscheiden ist.

In der Zwischenzeit habe ich das erstmal über Precompiler und ifdef mit einem globalem Debuglevel gelöst. Erkennt man im Quelltext besser.
Eingeschalten wird das über eine Option beim configure, erzeugt wird dabei beim Programmablauf eine zusätzliche expansive Ausgabe. Von dieser Ausgabe erhoffe ich mir den Programmablauf an einigen Schlüsselpositionen beobachten zu können. Ist zwar noch nicht optimal. Aber erst mal sehen in wieweit es überhaupt beim User benötigt wird. Bin jetzt noch am Überlegen beides zu kombinieren, also eine als Debug kompilierte Version über Debug Aufrufoptionen zusätzlich noch zu steueren, um dann immer nur bestimmte Informationsgebiete überwachen zu können und nicht wie jetzt, immer alles oder nichts.

Ich markiere das Thema mal als gelöst, wenn noch jemanden irgend eine großartige Idee hat, bin nach wie vor an anderen Ansätzen und Erfahrungen interessiert.

robi