3. Wie findet ihr total erratische Fehler ?

Wie findet ihr total erratische Fehler ?

  • ?

    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