it-swarm.com.de

Warum wird Reverse Debugging selten verwendet?

gdb implementierte 2009 Unterstützung für Reverse Debugging (mit gdb 7.0). Ich habe bis 2012 noch nie davon gehört. Jetzt finde ich es äußerst nützlich für bestimmte Arten von Debugging-Problemen. Ich wünschte, ich hätte schon einmal davon gehört.

Korrigieren Sie mich, wenn ich falsch liege, aber ich habe den Eindruck, dass die Technik immer noch selten angewendet wird und die meisten Menschen nicht wissen, dass sie existiert. Warum?

Kennen Sie Programmiergemeinschaften, in denen Reverse Debugging häufig verwendet wird?

Hintergrundinformation:

57
Philipp Claßen

Zum einen ist das Ausführen im Debug-Modus bei aktivierter Aufzeichnung sehr teuer im Vergleich zum normalen Debug-Modus. es verbraucht auch viel mehr Speicher.

Es ist einfacher, die Granularität von Leitungsebene auf Funktionsaufrufebene zu verringern. Mit dem Standard-Debugger in Eclipse können Sie beispielsweise "zum Frame fallen lassen". Dies ist im Wesentlichen ein Sprung zurück zum Start der Funktion mit einem Zurücksetzen aller Parameter (nichts, was auf dem Heap getan wurde, wird zurückgesetzt, und finally Blöcke werden nicht ausgeführt, es handelt sich also nicht um einen echten Reverse-Debugger (seien Sie vorsichtig).

Beachten Sie, dass dies seit mehreren Jahren verfügbar ist und mit dem Ersetzen von Hotcodes einhergeht.

27
ratchet freak

Wie bereits erwähnt, ist die Leistung der Schlüssel, z. Mit dem reversiblen Debugging von gdb führt das Ausführen von gzip zu einer Verlangsamung von 50.000x im Vergleich zum nativen Ausführen. Es gibt jedoch kommerzielle Alternativen: Ich arbeite für Undo ndo.io , und unser UndoDB-Produkt macht dasselbe, jedoch mit einer Verlangsamung von weniger als 2x. Es gibt auch andere kommerzielle reversible Debugger.

11
user1839284

Eine Übersicht über die Technologieoptionen und -produkte finden Sie in einer Reihe von Blog-Posts, die ich vor etwa einem Jahr geschrieben habe (und einige Folgemaßnahmen seitdem):

Mein Gefühl dafür, warum es so wenig verwendet wird, ist, dass es spezielle Hardware erfordert, einen speziellen Debugger verwendet oder Ihr System richtig einrichtet. Leider investieren die meisten Menschen nicht die Zeit, um den maximalen Nutzen aus ihren Debug-Tools zu ziehen.

Und die Tatsache, dass der "billige Standard" von gdb fast ungewöhnlich langsam ist und einige Stabilitätsprobleme für alles außer den gängigsten Zielsystemen hat.

10
jakobengblom2

Aus meiner Erfahrung als Vertriebsingenieur für den TotalView-Debugger wissen die Leute, dass es ihn gibt, aber sie glauben nicht, dass er funktioniert, unabhängig von der (akzeptablen oder nicht akzeptablen) Verlangsamung.

Die Universität von Cambridge hat kürzlich eine Umfrage mit dem Titel "Nichteinführung von Reverse-Debugging-Kosten für die Weltwirtschaft jährlich 41 Milliarden US-Dollar" durchgeführt.

Und als ich zu GDB zurückkam, habe ich (viel) gehört, dass die Verlangsamung es für eine "echte" Anwendung ziemlich unbrauchbar macht.

Ich persönlich würde gerne von mehr Leuten hören, die Reverse-Debugging für andere Anwendungen als "Hallo Welt!"

4
SebGR

Ich denke, es ist wichtig, dieses "umgekehrte" oder "historische" Debugging etwas weiter auszubauen. Ich denke, komplexe Systeme und Verhaltensweisen in diesen zu verstehen und "Ereignisse" wiederzugeben, die den Zustand explizit machen, ist absolut entscheidend.

Ich möchte zum Ausdruck bringen, dass Sie sich nicht allein fragen, warum diese Technik heute nicht so häufig angewendet wird oder warum die damit verbundenen Probleme selten klar diskutiert werden.

Lassen Sie uns hier zwei sehr wichtige Konzepte hervorheben:

1. Um ein Programmiersystem zu verstehen, ist es hilfreich, den Status explizit anzugeben

2. Um ein Programmiersystem noch besser zu verstehen, kann die Wiedergabe von Zustandssequenzen (Ereignissen) sehr hilfreich sein.

Hier sind einige Quellen, die sich mit dem Problem befassten und Lösungen für das Problem vorschlugen oder entwarfen (Umgang mit dem Zustand in komplexen Systemen):

-Aus dem Teerbit, Papier: http://shaffner.us/cs/papers/tarpit.pdf Hauptideen: Vermeiden, isolieren oder expliziten Status

-CQRS http://www.cqrs.nu/ Dies ist eine Kombination aus zwei Konzepten: Command Query Segregation und Event Sourcing. Es gibt verschiedene Implementierungen (Java, C #, Scala). Die Wiedergabe von Tate-Sequenzen und die Entwicklung eines Domänenmodells sind hier die entscheidenden Teile.

Wenn Sie wirklich herauszoomen und das sehr breite Bild sehen, können Sie bereits sehen, dass Menschen mit dem "Aufstieg" der funktionalen Programmierung bereits ((un) bewusst) sind ) von fp angezogen, weil es den Zustand explizit macht! Aber das betrifft nur Punkt eins, um den zweiten anzusprechen, benötigen Sie ein anderes Konzept, das "lose" als funktionale reaktive Programmierung beschrieben werden könnte.

Sie könnten also alles gut und schön sagen, aber wer verwendet eigentlich CQRS und FRP? Ich würde sagen (IMO, weil ich keine konkreten Zahlen habe), dass viele Unternehmen nur wissen, dass ihre Arbeit diese Terminologie hat. Vielleicht googeln Sie ein bisschen herum und hören von Unternehmen, die CQRS verwenden. Es gibt bereits einige Erfolgsgeschichten. Auch FRP steigt langsam als Beispiel, das ich Netflix geben könnte: http://techblog.netflix.com/2013/02/rxjava-netflix-api.html Was gerade eine Implementierung von RX veröffentlicht hat, das ist Eigentlich .NET-basiert (hat aber auch eine Javascript-Implementierung). Daher verwenden die Menschen diese Techniken bereits heute, IN DER GROSSEN, um komplexe Systeme zu verstehen und sie noch besser zu machen. Aus diesem Grund verwenden sie Reverse-Debugging-Techniken.

2