3. Wie findet ihr total erratische Fehler ?

Wie findet ihr total erratische Fehler ?

  • ?

    Der MSVS kann das, aber die Linuxfrickelsoftware nicht 😃 👎

    0
  • A

    jaaber schrieb:

    Der MSVS kann das, aber die Linuxfrickelsoftware nicht 😃 👎

    Ach so, deswegen läuft die gefrickelte Linux Software so instabil - weil man dort keine vernünftigen Debugger hat ! Vielleicht sollte sich der eine oder andere mal darüber Gedanken machen...

    0
  • ?

    abc.w schrieb:

    Ach so, deswegen läuft die gefrickelte Linux Software so instabil - weil man dort keine vernünftigen Debugger hat ! Vielleicht sollte sich der eine oder andere mal darüber Gedanken machen...

    hehe, seltsamerweise ist der windows-kernel sehr stabil, während die usermode-anwendungen sich vor bugs überschlagen, obwohl man im kernel, im vergleich zu usermode, nur rudimentäre debugging-techniken anwenden kann. woran liegt das nur?
    🙂

    0
  • H

    ~fricky schrieb:

    abc.w schrieb:

    Ach so, deswegen läuft die gefrickelte Linux Software so instabil - weil man dort keine vernünftigen Debugger hat ! Vielleicht sollte sich der eine oder andere mal darüber Gedanken machen...

    hehe, seltsamerweise ist der windows-kernel sehr stabil, während die usermode-anwendungen sich vor bugs überschlagen, obwohl man im kernel, im vergleich zu usermode, nur rudimentäre debugging-techniken anwenden kann. woran liegt das nur?
    🙂

    statistische schwankung.

    0

  • Ein Debugger ist ein Werkzeug. Wer es nicht richtig einsetzen kann, wird nicht viel davon haben. Wer versucht es auf das falsche Problem anzuwenden, wird auch nicht sehr weit damit kommen. Und um es richtig einsetzen zu können bedarf es einiger Übung und Erfahrung.

    0
  • K

    Um mal auf das Thema zurückzukommen:
    1.) Fehlerszenario stabilisieren ( wenn reproduzierbar ).
    2.) Fehler eingrenzen und involwierte Klassen / Funktionen lokalisieren (was läuft schief, wo läuft etwas schief).
    3.) Fehler verstehen, ggf. Hypothesen aufstellen, was falsch läuft.
    4.) Beheben und schauen, ob der Fehler immer noch auftritt.

    Aber gerade nicht reproduzierbare Fehler, die man nur einmal gesehen hat bzw. sich nur nach längerer Laufzeit einstellen ( ich entsinne mich an ein Szenario, daß nach 3-4 Wochen Dauertest aufgetreten ist ), versuche ich, den Stand wenn möglich erst einmal zu konservieren und gehe mit dem Debugger ran ( gern WinDbg, unter Linux gdb oder ddd, die tun auch ihren Dienst ). Und gerade bei Fehlern in Multithread-Anwendungen mit vielen Nebenläufigkeiten kann das ganz schön eklig werden. Vom Timing will ich gar nicht erst reden ^^.

    Ansonsten halt die üblichen Verdächtigen.
    - Defensiven Code mit möglichst vielen asserts schreiben.
    - Printf einsetzen, um zu verstehen, was kaputt ist.
    - Logs durchwühlen.
    - Code gegenlesen.
    - Code verstehen ( gerade bei fremden Code je nach autor eine kleine bis große Herausforderung 😉 )
    und und und.
    - Kollegen das Problem beschreiben, um das Brett vom Hirn wegzubekommen.
    - Pair-Debugging, sofern möglich

    Gruß Kimmi

    0
  • P

    Ich stehe meist vor der Situation, daß printf() primär mal nicht funktioniert (wg. Microcontroller). Früher, als BDM (background debug mode) selten und ICE (in circuit emulator) brutal teuer waren, hat man sich einen Grundstock an Primitiv- Debug- Mitteln angeeignet, die immer funktionieren:

    Erstmal Hardware checken:
    - Fön und Kältespray helfen, schlechte Lötungen, Haarrisse und dergl. auszuschließen.
    - offene Pins mit Entmagnetisierungsdrossel, Logic Pen und Fingerspitze finden.
    Erst, wenn sich die Schaltung davon unbeeindruckt zeigt, Software nochmal unter die Lupe nehmen.

    Ohne Debugger waren meine Breakpoints Endlosschleifen auf Pintoggles, weil die UART meist in Benutzung war, später kam ein Display dazu, auf dem ich seriell Werte rausshiften konnte. Weil das alles so mühselig (enorme Turnaroundzeiten) war, bekam das CodeViewing hohen Stellenwert. Vorzugsweise in ausgedruckter Form, mit 'nem Krickelstift dazu und weg von der Hardware, in den Garten, die Kantine oder aufs Klo 😉 .

    Seit dem Aufkommen bezahlbarer und leistungsstarker Debugger möchte ich nie wieder mit den Primitivmethoden arbeiten, das geht sogar so weit, daß ich bei Pinmangel auf dem Targetprozessor erstmal das Flaggschiff aus der Familie layoute und erst wenn alles geht, ein zweites Layout hinterherschiebe, das kostet insgesamt weniger, als während der gesamten Entwicklung nicht bequem sehen zu können, was in der Software vor sich geht.

    Geblieben ist mir der Hang, Papier auszudrucken und nach Tapetenwechsel über den Käse nachzudenken, den ich fabriziert habe. Zumeist fallen mir mindestens Sachen auf, die man geschickter hätte machen können, oftmals hat die Klo- Debug- Session schon geholfen, den Scheiß- Fehler zu finden 😃 !

    Gestern hatte ich z.B. so einen Verzweiflungsfall, bin über dem Print eingeschlafen und gegen halb eins in die Kiste gekrochen. Als ich um sechs Uhr wieder hochgestolpert bin und die papers mit 'nem halben Blick sah, war mir schlagartig klar, wo der Fehler sitzt. Trotzdem hab' ich bis vorhin die Lösung mit dem Debugger auf Herz und Nieren geprüft, mit printf()- Orgien quäle ich mich da aber gar nicht erst ab, selbst, wenn sie möglich sind.

    Die Kombination aus Code Viewing und Debugger macht's!

    0
  • K

    Was meiner Erfahrung nach auch ein toller Lösungsweg ist: für 1-2 Stunden spazierengehen und was anderes machen. Danach ist man nicht mehr so codeblind.

    Und eine ganz spezielle Problemlösung, die mir mal den Hals gerettet hat:
    Nach einem Monat Debugging eines einen eigenen FE-Solvers habe ich mich bis um 4 Uhr morgens in die Kneipe gesetzt, da ich massivst frustiert war. Am nächsten Morgen um 8:00 Uhr aufgestanden und zack, hatte ihn. Nur weiterempfehlen kann man das nicht wirklich ;-).

    Gruß Kimmi

    0
  • ?

    pointercrash() schrieb:

    Ich stehe meist vor der Situation, daß printf() primär mal nicht funktioniert (wg. Microcontroller).

    bei mir ist 'printf' meistens auch nur ein 'puts' auf irgendeine schnittstelle zur aussenwelt. irgendein debugger (war's keil µvision?) konnte eine rs232 simulieren und obwohl nix angeschlossen war, die ausgaben in einem debugfenster anzeigen.
    'printf'-debugging ist toll, um abläufe zu visualisieren. damit entdeckt man z.b. dinge, die sich so nicht als fehler bemerkbar machen, aber trotzdem falsch laufen.
    🙂

    0
  • V

    Zum Thema Debugging, gibt es ein äußerst gut geschriebenes Buch von

    David J. Agans:
    "Debugging—The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems"
    ISBN 0−8144−7168−4

    Das Buch bezieht sich nicht auf Programmierung oder deren Werkzeuge im Speziellen. Er stellt allgemeingültige Regeln zur erfolgreichen Fehlersuche auf und hinterlegt diese mit Beispielen und Geschichten "War stories", die äußerst amüsant zu lesen sind und erlären, warum ein Missachten dieser Regel zum ewigen suchen geführt hätte.

    Echt Lesenswert!

    0
  • ?

    http://www.debuggingrules.com/
    🙂

    0
  • R

    jaaber schrieb:

    Der MSVS kann das, aber die Linuxfrickelsoftware nicht 😃 👎

    Der GDB kann das natürlich auch. 🙄

    0
  • P

    ~fricky schrieb:

    bei mir ist 'printf' meistens auch nur ein 'puts' auf irgendeine schnittstelle zur aussenwelt. irgendein debugger (war's keil µvision?) konnte eine rs232 simulieren und obwohl nix angeschlossen war, die ausgaben in einem debugfenster anzeigen.
    'printf'-debugging ist toll, um abläufe zu visualisieren. damit entdeckt man z.b. dinge, die sich so nicht als fehler bemerkbar machen, aber trotzdem falsch laufen.
    🙂

    Keil C war Anfang der 90er ein Grund für mich, meine Arbeiten in C auf das Geringstmögliche zu reduzieren, weiß also nicht, ob die ihren damaligen Schrott auf ein annehmbares Niveau heben konnten.

    Die meisten meiner Debugger haben so ein Highlighting, daß ich nichtmal Watches anlegen muß, wenn's das "mouseover"- Event auch tut. Eventuell, um Gültigkeitsbereiche mit 'nem halben Auge mitzuverfolgen. Aber vielleicht ist das einfach so, daß man sich so an eine Arbeitsweise gewöhnt hat und die andere einfach nicht für sich in Betracht zieht. Printf() ist ja quasi die Luxus- Variante des Toggle- Pins und ich habe wohl einfach zu viel Zeit damit verbracht, Hex- Kryptik auf 'nem Debug- Display zu interpretieren, als daß ich das überhaupt nur in Erwägung zöge.

    Vom Hardcore- ASM- Freak zum C-Spy- Weichei quasi ... 😉

    0
  • S

    rüdiger schrieb:

    Superlexx schrieb:

    bei noch härteren Fällen greife ich schon mal auf das "reverse debugging" über VMware + VS zurück.

    Was ist das? Ring0 debuggen, ala SoftICE oder RR0D?

    Nein, die VM macht eine Aufnahme, während das zu debuggende Programm darin läuft, und lässt später Ereignisse auf ihre Ursachen zurückführen, da das Programm sich dann im Abspielmodus stets identisch verhält. Es gibt dann Sachen wie "Replay to the previous breakpoint or exception" oder "Replay in reverse to the cursor location".

    0
  • A

    ~fricky schrieb:

    http://www.debuggingrules.com/
    🙂

    Naja, wäre denn nicht das hier lehrreicher: http://www.gnu.org/software/gdb/documentation/ . Vermute, die ganzen MSVS Nutzer werden beim Durchlesen der obigen Doku depressiv...

    0
  • B

    Was ist ein "erratischer" Fehler? Meinst Du "erotischer" Fehler, dann bist Du hier im falschen Forum!

    0
  • ?

    abc.w schrieb:

    Naja, wäre denn nicht das hier lehrreicher: http://www.gnu.org/software/gdb/documentation/ . Vermute, die ganzen MSVS Nutzer werden beim Durchlesen der obigen Doku depressiv...

    ja, gdb benutzen ist kein spass. das kann schon ziemlich frustrierend sein, wenn man andere debugger kennt.
    🙂

    0
Anmelden zum Antworten