Perché il debug inverso viene utilizzato raramente? [chiuso]

57

gdb ha implementato il supporto per il debug inverso nel 2009 (con gdb 7.0). Non ne ho mai sentito parlare fino al 2012. Ora lo trovo estremamente utile per alcuni tipi di problemi di debug. Ho desiderato di averne sentito parlare prima.

Correggimi se sbaglio, ma la mia impressione è che la tecnica sia ancora usata raramente e la maggior parte delle persone non sa che esiste. Perché?

Conosci qualche comunità di programmazione in cui l'uso del reverse debugging è comune?

Informazioni di base:

StackOverflow: come funziona il debug inverso?
gdb usa il termine "reverse debugging" ma altri fornitori usano altri termini per tecniche identiche o simili:
- Microsoft lo chiama IntelliTrace o "Debug storico"
- C'è un debugger inverso Java chiamato Omniscient Debugger , anche se probabilmente non funziona più in Java 6
- Esistono altri debugger inversi Java
- Il debugger di OCaml (ocamldebug) lo chiama viaggiare nel tempo

debugging

— Philipp Claßen
fonte

47

A beneficio di coloro che non sanno che esiste, che cosa è il debug inversa?

— Mason Wheeler,

5

MS ha chiamato il loro intellitrace di sistema che sembra essere simile a quello che chiamate revese debugging, potrebbe essere una questione di più nomi a seconda dell'ambiente che lo rende meno usato.

— Ryathal,

1

Solo per quello che vale: è davvero molto più vecchio di quanto pensiate - Microsoft lo ha supportato in QuickC (intorno al 1989 o '90, se la memoria serve).

— Jerry Coffin,

41

@MasonWheeler, chiaramente il reverse debugging è l'atto di aggiungere bug al codice. Non sono d'accordo con la premessa del PO secondo cui si tratta di una pratica non comune.

— Ben Lee,

3

@BenLee, chiamiamo quel rifiuto.

— OldFart

27

Per uno, l'esecuzione in modalità debug con registrazione attiva è molto costosa rispetto alla normale modalità debug; consuma anche molta più memoria.

È più semplice ridurre la granularità dal livello di linea al livello di chiamata funzione. Ad esempio, il debugger standard in eclipse consente di "rilasciare al frame", che è essenzialmente un ritorno all'inizio della funzione con un ripristino di tutti i parametri (non viene ripristinato nulla fatto sull'heap e i finallyblocchi non vengono eseguiti , quindi non è un vero debugger inverso; fai attenzione).

Si noti che questo è disponibile da diversi anni e funziona di pari passo con la sostituzione dell'hot-code.

— maniaco del cricchetto
fonte

1

Ottima risposta Posso confermare che la registrazione è costosa. Devi abilitarlo poco prima di entrare nella parte critica della tua applicazione, che non è sempre banale. Concordo anche sul fatto che "drop to frame" è spesso abbastanza buono. Tuttavia, non funziona bene con loop o algoritmi ricorsivi.

— Philipp Claßen,

3

Questo fino a quando rr ( rr-project.org ). la velocità durante la registrazione di un'esecuzione usando rr è appena più lenta. Puoi quindi riprodurre, intervenire, riavvolgere, impostare gli osservatori nel tuo IDE preferito ( github.com/mozilla/rr/wiki/Using-rr-in-an-IDE ) ... Il modo in cui esegui il debug del codice non sarà mai il stesso.

— jyavenard,

11

Come già accennato, le prestazioni sono fondamentali, ad esempio con il debug reversibile di gdb, l'esecuzione di qualcosa come gzip vede un rallentamento di 50.000 volte rispetto all'esecuzione nativa. Esistono comunque alternative commerciali: lavoro per Undo undo.io e il nostro prodotto UndoDB fa lo stesso, ma con un rallentamento inferiore a 2x. Sono disponibili anche altri debugger commerciali reversibili.

— user1839284
fonte

1

Interessante, lo proverò sicuramente. In diversi articoli, si afferma che è gratuito per uso non commerciale ma non ho trovato informazioni che lo confermino sulla tua homepage. È ancora vero? Grazie per aver rivelato la tua affiliazione.

— Philipp Claßen,

2

Quali sono i prezzi per le versioni Starter e Professional di UndoDB? Non li vedo nella pagina delle edizioni UndoDB.

— Tcrosley,

3

Come state ragazzi rispetto a Mozilla rr?

— Ciro Santilli 9 改造中心法轮功六四事件

10

Per una panoramica delle scelte tecnologiche e dei prodotti, vedere una serie di post sul blog che ho scritto circa un anno fa (e alcuni follow-up da allora):

http://jakob.engbloms.se/archives/1547 - the tech
http://jakob.engbloms.se/archives/1554 - ricerca
http://jakob.engbloms.se/archives/1564 - prodotti
http://jakob.engbloms.se/archives/1768 - aggiornamenti al post precedente

La mia sensazione sul perché sia usato così poco è che richiede hardware speciale, o l'utilizzo di un debugger speciale o l'impostazione corretta del sistema. La maggior parte delle persone non investe il tempo per ottenere il massimo valore dai propri strumenti di debug, sfortunatamente.

E il fatto che il "default economico" di gdb è quasi insolitamente lento e presenta alcuni problemi di stabilità per tutto tranne che per i sistemi target più comuni.

— jakobengblom2
fonte

4

Dalla mia esperienza come ingegnere di vendita per il debugger di TotalView, le persone sanno che esiste ma non pensano che funzioni, indipendentemente dal rallentamento (accettabile o meno).

L'Università di Cambridge ha recentemente condotto un sondaggio dal titolo "Il fallimento nell'adottare i costi di debug inversi nell'economia globale $ 41 miliardi all'anno" .

E tornando a GDB, ho sentito (molto) che il rallentamento lo rende piuttosto inutilizzabile su un'applicazione "vita reale".

Personalmente mi piacerebbe ricevere notizie da più persone che utilizzano il debug inverso su applicazioni diverse da "Hello world!"

— SebGR
fonte

4

Penso che sarebbe molto meglio collegare questo studio piuttosto che lo spam "Undo Software" che finge di studiare.

— Bulwersator,

1

Nel mio precedente lavoro, ho lavorato alla creazione di un debugger inverso ( ghs.com/products/timemachine.html ). Abbiamo usato il debugger internamente pesantemente, e posso dirti, è stato incredibile. Ovviamente è stato fantastico per le condizioni di gara davvero pelose, ma è stato molto di più. Quando il debugging inverso è sempre attivo, la tua mentalità sul debug cambia. Si esegue meno iterazioni e si può fare meno attenzione a come testare il codice. Puoi anche salvare un'esecuzione e inviarla a qualcuno, quindi è ottimo per trovare bug nel codice di altre persone.

— speedplane il

2

Penso che sia importante ampliare ulteriormente questo debug "inverso" o "storico". Penso che comprendere sistemi e comportamenti complessi in quelli, riprodurre "eventi" che rendono esplicito lo stato sia assolutamente cruciale.

Quello che voglio esprimere è che non sei il solo a chiederti perché questa tecnica non è così tanto applicata oggi o perché i relativi problemi raramente vengono discussi chiaramente.

Diamo quindi risalto a due concetti molto importanti qui:

1.Per comprendere un sistema di programmazione è utile rendere esplicito lo stato

2.Per comprendere ulteriormente un sistema di programmazione, la riproduzione di sequenze di stato (eventi) può essere di grande aiuto.

Ecco alcune fonti che hanno affrontato il problema e proposto o progettato soluzioni per il problema (gestione dello stato in sistemi complessi):

-Del bit di bit, carta: http://shaffner.us/cs/papers/tarpit.pdf Idee principali: evitare, isolare o rendere esplicito lo stato

-CQRS http://www.cqrs.nu/ Questa è una combinazione di due concetti: segregazione di query di comando e sourcing di eventi. Esistono diverse implementazioni (Java, C #, Scala). La riproduzione delle sequenze di Tate e l'evoluzione di un modello di dominio sono le parti cruciali qui.

Se ingrandisci davvero e vedi l'immagine molto ampia puoi già vedere che con il "sorgere" della programmazione funzionale le persone sono già ((inconsapevolmente) attratte da fp perché rende esplicito lo stato! Ma questo riguarda solo il punto uno, per affrontare il secondo è necessario un altro concetto che potrebbe essere "liberamente" descritto come programmazione reattiva funzionale.

Quindi potresti dire tutto bene ma chi effettivamente utilizza CQRS e FRP? Direi (IMO perché non ho numeri concreti) in realtà molte aziende è solo che non conoscono il lavoro che fanno ha questa terminologia. Forse vai un po 'in giro su Google e senti le imprese che usano CQRS, ci sono già alcune storie di successo là fuori. Anche FRP sta aumentando lentamente come esempio che potrei dare a Netflix: http://techblog.netflix.com/2013/02/rxjava-netflix-api.html Che ha appena rilasciato un'implementazione di RX che in realtà è basata su .NET (ma ha anche un'implementazione Javascript). Quindi le persone utilizzano già queste tecniche oggi, IN THE LARGE per comprendere sistemi complessi e renderli ancora migliori. Questo è il motivo per cui usano tecniche di debug inverse.

— AndreasScheinert
fonte