Come posso risolvere un bug "emergente"?

5

Sto scrivendo un risolutore PDE e ho un bug che compare solo in casi di test molto grandi. Cioè, con piccole griglie il programma fornisce risposte corrette, ma c'è una grande quantità di errore non contabile (ho tenuto conto di arrotondamenti, discretizzazione e altri tipi standard di errore che inevitabilmente si verificano) che si insinua quando i miei casi di test ottengono nell'intervallo da un giorno all'altro.

Non posso eseguirlo in un debugger, ci vorrebbero settimane. E la stampa di risultati intermedi non è particolarmente utile dato che non riesco a controllare manualmente l'output per vedere cosa c'è che non va.

Come posso trovare e correggere questo bug "emergente"?

    
posta Dan 10.07.2014 - 22:56
fonte

3 risposte

2

Prima di tutto, rassegnati al fatto che questo richiederà probabilmente un lungo tempo per risolverlo. Ho avuto un bug qualche anno fa che ci è voluto quasi un anno per sistemarlo, perché era così dispendioso in termini di tempo da riprodurre.

Un consiglio è assicurarsi che il codice venga compilato senza avvisi e passi l'analisi statica. Ottieni una recensione tra pari. Potresti avere qualcosa come una condizione di gara con una probabilità dello 0,001% di verificarsi. Gli strumenti di analisi statica possono aiutarti a trovare questi tipi di bug.

Assicurati che il tuo codice sia super pulito. Elimina tutti la ripetizione e riduci le tue funzioni. Elimina tutte le ottimizzazioni che potresti aver fatto e sostituiscile con un codice che è così semplice da leggere, eventuali errori si diffonderanno come un pugno. Solo dopo che il tuo codice funziona dovresti reinserire le ottimizzazioni, una per una con un test tra una e l'altra. Il codice che è più difficile da leggere è il codice che con ogni probabilità contiene un bug.

Scrivi un ton di test unitari, che coprono tutti i casi limite del tuo errore contabilizzato. Lo scenario più probabile è che tu abbia fatto un errore accidentalmente con uno di loro.

La prossima cosa che puoi fare è scrivere del codice extra per aiutarti a individuare e restringere il bug. Caricalo con asserzioni e voci di registro. Automatizza il rilevamento del bug nei tuoi risultati intermedi, magari confrontandolo con un algoritmo più lento ma più affidabile. Scrivi il codice per verificare le condizioni che dovrebbero essere impossibili da colpire, quindi imposta un punto di interruzione se lo fa. Rendi possibile salvare e riavviare il tuo algoritmo da uno stato intermedio.

Un'altra tecnica interessante che ho visto di recente ha dimostrato di avere un grande effetto in questo eccellente TED talk è quello di creare una visualizzazione. Il cervello umano può trovare schemi e anomalie molto, molto più facilmente in forma visiva.

Sottolineerò nuovamente la necessità di essere paziente. Se provi a correre e cerchi di prendere scorciatoie, probabilmente ti ci vorrà più tempo. Non aver paura di apportare grandi cambiamenti al solo scopo di eseguire il debug. Non sprecerai il tuo sforzo precedente, questo è il motivo del controllo del codice sorgente.

    
risposta data 11.07.2014 - 00:04
fonte
8

Alcuni suggerimenti:

  1. Una cosa che puoi fare è provare a restringere il problema attraverso bisezione geometrica . (L'ho usato con discreto successo nello studio dei fallimenti della rigenerazione CAD per caratteristiche geometriche estremamente complesse.) L'idea qui è di dimezzare il modello in errore, quindi vedere se il problema si riproduce su ciascuna metà. In questo modo potresti essere in grado di restringere un volume specifico del tuo modello che fa perdere il controllo al tuo risolutore.

  2. In secondo luogo, la maggior parte dei debugger può collegarsi a un processo già in esecuzione. Se in qualche modo puoi aggiungere un test al tuo solutore per rilevare quando gli errori stanno iniziando a perdere il controllo (questo test potrebbe essere codificato per il modello specifico e la simulazione che presenta il problema), il codice di test può sospendere l'esecuzione (alzando un "problema trovato, premi OK" se non altro), e puoi quindi collegare il debugger per vedere cosa è successo.

  3. In modo simile, puoi fare un test che è così matematicamente banale che è risolvibile analiticamente ed eseguire quel test case su una griglia molto grande? Potresti essere in grado di vedere come si accumulano gli errori dato che conosci la risposta corretta in anticipo.

  4. Fa parte del problema che la tua workstation sia lenta e in qualche modo obsoleta? Potresti essere in grado di dimostrare alla tua amministrazione che l'hardware deve essere aggiornato per consentire il debug di simulazioni realistiche dei clienti.

risposta data 10.07.2014 - 23:32
fonte
0

Esaminare un caso di test passeggero che assomigli da vicino alla situazione in errore. Quindi guarda cosa fanno diversamente. Forse anche modificare il test di passaggio in modo che sia più vicino nel comportamento al test in errore. Se improvvisamente inizia a fallire, sai dove iniziare a cercare.

    
risposta data 10.07.2014 - 23:10
fonte

Leggi altre domande sui tag