Debug di un processo lento [chiuso]

È possibile salvare calcoli parziali? In tal caso, potresti salvare l'insieme di calcoli che sai essere buoni, quindi ricaricarli durante le sessioni future e continuare a eseguire il debug da lì.

Se i test sono riproducibili, come il 1.058esimo elemento del 99 ° array di frobaz finisce sempre male, puoi mettere un punto di controllo su quella posizione di memoria e dare il via ai tuoi calcoli. Mentre scorre i calcoli lenti, è possibile esaminare il codice manualmente per vedere se qualcosa risalta. Alla fine, si fermerà quando quell'elemento verrà modificato. Da lì di solito puoi vedere da dove proviene l'input sbagliato. (Probabilmente un calcolo con un altro elemento negativo, quindi puoi provare di nuovo con quell'elemento .

Inoltre, consiglio vivamente di eseguire un analizzatore statico sul tuo codice. Potrebbe indicare un problema nel codice che non hai notato e indicare da dove proviene l'errore. Altri strumenti come valgrind, disinfettanti per indirizzi, ecc. Aiutano anche a questo proposito.

Modifica mi viene in mente che puoi "congelare la macchina" in un certo senso. Se hai una macchina virtuale puoi avviare la tua app ed eseguire i calcoli fino al punto in cui vuoi iniziare il debug. Salva lo stato delle macchine virtuali. Fai il tuo debugging Quando si desidera tornare a quello stato è sufficiente ripristinare la VM nel punto in cui è stata salvata e iniziare nuovamente il debug. Ovviamente, se si modifica un codice, è necessario eseguire nuovamente i calc up fino al punto in cui si desidera eseguire il debug.

Does one know a debugging strategy which can help to reduce the waiting time until a breakpoint is reached in the area of the code which is suspected to contain the cause?

È ancora possibile profilare le funzioni di debug. Non impiegherei troppo tempo su di esso, specialmente con un bug da correggere, ma se hai un glaciale hotspot che impiega il 30% del tempo o più nel debug, e la soluzione è super semplice, allora potrebbe fare un vero e proprio differenza di produttività se gli sviluppatori sono abituati a spendere oltre 30 minuti in attesa delle build di debug per fare qualcosa e persino aiutarti a correggere il bug prima.

Nel mio caso abbiamo avuto una libreria matrix / vector una volta che si è svolta in modo bello nei build di rilascio / produzione, ma abbiamo disseminato le asserzioni ovunque per assicurarsi che non stessimo accedendo agli array fuori limite e così via nei build di debug. Ho trovato degli hotspot grossolani (come oltre il 50% del tempo speso in tali funzioni a causa di asserts dappertutto), e ho finito per scrivere un test unitario che ha fatto sì che quelle funzioni si comportassero correttamente e rendesse solo quelle asserts applicato quando qualcosa come DEBUG_MATH_LIB (ho dimenticato quello che ho chiamato, questo era molti anni fa) è stato definito. Questo ha accelerato il funzionamento del software in modalità debug in modo sostanziale in cui, da tortura completa, tenta di riprodurre i problemi nel debugger in modo non troppo insopportabile (il debug era ancora 20 volte più lento del rilascio, ma non 200 volte più lento). / p>

Se stai provando a riprodurre un bug che genera output difettoso (o crash o altro) e impiega anni, di solito la mia tecnica numero uno, se applicabile, quando ero abituato a trattare con quello era cercare di giocare con il contenuto con una mentalità di "ricerca binaria" e originariamente in una build di rilascio (non sto eseguendo il debugger).

Potrei provare a caricare metà del contenuto (dopo aver salvato l'intero contenuto meno la metà di esso eliminato) e vedere se funziona male. Se non lo fa, provo l'altra metà e scopro che si sbaglia. Poi divido la seconda metà in quarti, e così via, fino a quando ci vogliono solo pochi secondi per caricare e riprodurre il problema. Dopo di ciò, il problema principale che questo problema impiega così tanto tempo a riprodursi è risolto, e il resto è il doloroso processo di debugging del collo di bottiglia in attesa di riprodurlo. Sono passati molti anni da quando dovevo fare questo genere di cose (ho trovato disegni che evitavano questo genere di cose per la maggior parte), ma i miei ricordi confusi del passato ricordano di aver fatto molte cose.

La maggior parte delle volte non è necessario caricare 3 gigabyte di dati per riprodurre un problema. Il primo passo per me non è capire il problema, ma renderlo più veloce da riprodurre con quella mentalità di "ricerca binaria", dimezzare i dati finché non è così piccolo che si carica in un batter d'occhio e causa il problema. Quindi mi occupo della mia "modalità di debug". Questo restringimento dei dati tende anche a rendere più ovvio quale parte di esso potrebbe far inciampare nel software.

Ideally I would like to save the process state right before (what I believe is) the buggy section and then debug from that point. I dont think this is possible.

Almeno su Windows, puoi fare clic con il tasto destro del mouse su qualsiasi processo in esecuzione e generare un file di dettagli.

Puoi quindi aprire il file .DMP risultante in, ad esempio, Visual Studio e andare direttamente nel debugging.

Sfortunatamente ciò non consente di riprendere il processo a mia conoscenza e di lasciarlo terminare (fare i dump di solito mi sono utili solo quando il software si blocca). Tuttavia, può essere un modo per salvare un dump dello stack e ispezionare le cose ed essere in grado di tornare indietro e guardarle ancora.