Perché il debugging inverso viene usato raramente? [chiuso]

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

È più facile ridurre la granularità dal livello di linea al livello di chiamata della funzione. Ad esempio, il debugger standard in eclissi consente di "rilasciare al frame", che è essenzialmente un salto indietro all'inizio della funzione con un reset di tutti i parametri (non viene eseguito nulla sull'heap e i blocchi finally non vengono eseguiti, quindi non è un vero debugger inverso, fai attenzione a questo).

Da notare che questo è disponibile da diversi anni e funziona a braccetto con la sostituzione del codice sorgente.

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

• link - la tecnologia
• link - ricerca
• link - prodotti
• link - aggiornamenti al post precedente

La mia sensazione per il motivo per cui viene usata 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 sia quasi insolitamente lento e abbia alcuni problemi di stabilità per tutto tranne che per i sistemi di destinazione più comuni.

Come già accennato, la performance è la chiave ad es. con il debugging reversibile di gdb, eseguire qualcosa come gzip vede un rallentamento di 50.000x rispetto al funzionamento nativo. Esistono tuttavia alternative commerciali: lavoro per Annulla undo.io e il nostro prodotto UndoDB fa lo stesso, ma con un rallentamento inferiore a 2x. Sono disponibili anche altri debugger reversibili commerciali.

Dalla mia esperienza come tecnico vendite per il debugger TotalView, la gente sa che esiste ma non pensa che funzioni, indipendentemente dal rallentamento (accettabile o meno).

Recentemente, l'Università di Cambridge ha effettuato un sondaggio dal titolo "Mancata adozione dei costi di debug invertire l'economia globale $ 41 miliardi all'anno" .

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

Personalmente mi piacerebbe sentire di più da persone che usano il reverse-debug su applicazioni diverse da "Hello world!"

Penso che sia importante approfondire ulteriormente questo debug "inverso" o "storico". Penso che comprendere i sistemi e il comportamento complessi in questi, per riprodurre "eventi" che rendono esplicito lo stato è assolutamente cruciale.

Ciò che voglio esprimere è che non sei il solo a chiedermi perché questa tecnica non viene applicata tanto oggi o perché i problemi correlati vengono discussi raramente in modo chiaro.

Quindi enfatizziamo due concetti molto importanti qui:

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

2.Per capire ancora meglio un sistema di programmazione che riproduce sequenze di stati (eventi) può aiutare molto.

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

-Out di tar bit, paper: link Principali idee: evitare, isolare o rendere esplicito lo stato

-CQRS link Questa è una combinazione di due concetti: Comando Query Segregation e Event Sourcing. 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 veramente riduci e vedi l'immagine molto ampia puoi già vedere che con "l'ascesa" della programmazione funzionale le persone sono già ((non) consapevolmente) attratte da fp perché rende lo stato esplicito! Ma questo riguarda solo il primo punto, per affrontare il secondo è necessario un altro concetto che possa essere definito "liberamente" come programmazione reattiva funzionale.

Quindi potresti dire tutto bene ma chi usa effettivamente CQRS e FRP? Direi (IMO perché non ho numeri concreti) in realtà un sacco di aziende è solo che non sanno che il lavoro che fanno ha questa terminologia. Forse fai un po 'di google e senti parlare di aziende che usano CQRS, ci sono già alcune storie di successo. Anche FRP sta salendo lentamente come un esempio che potrei dare a Netflix: link Che ha appena rilasciato un'implementazione di RX che è in realtà basato su .NET (ma ha anche un'implementazione Javascript). Quindi le persone stanno già usando queste tecniche, IN GRANDE, per comprendere sistemi complessi e renderli ancora migliori. Questo è il motivo per cui usano tecniche di reverse reverse.