Bug di tanto in tanto, ma con priorità alta

Funziona attorno

Poiché ChrisF suggerisce, la soluzione pragmatica a breve termine potrebbe essere quella di utilizzare sospendere e riprendere trucco, ma devi parlare con i tuoi clienti per sapere quali dovrebbero essere le tue priorità. Ad esempio:

• Se l'errore traspone una parte di £ 1000 o causa 4 ore di interruzione una volta alla settimana, mentre la correzione di pausa-resume riduce la produzione dell'1%, probabilmente preferirà la correzione in questo momento.

• Se l'errore traspone una parte £ 1 o causa 4 minuti di inattività una volta alla settimana, ma la correzione pausa-resume riduce la produzione dell'1%, probabilmente preferiranno attendere una correzione che non influisce tasso di produzione.

Avendo lavorato nel settore della microlavorazione laser per molti anni, so quanta pressione si può sopportare per ottimizzare il processo e fare in modo che la macchina produca il maggior numero di pezzi all'ora possibile, quindi in ogni caso essere sotto pressione per risolvere il problema correttamente.

Accesso

Nella mia esperienza, l'unico modo per rintracciare efficacemente un Heisenbug è una registrazione abbondante. Registrare tutto dentro e intorno alla parte del codice che potrebbe essere responsabile dell'errore. Scopri come leggere i tuoi file di registro in modo efficace, assicurati di monitorare l'errore seguente sui tuoi motori (le tue fasi si stanno spostando dove dovrebbero quando dovrebbero?). Guarda l'utilizzo della memoria sulla macchina, c'è una perdita di memoria che causa la morte di un processo critico?

Assicurati di registrare anche le azioni degli utenti, sei sicuro che l'operatore non stia colpendo l'arresto di emergenza in modo che possano saltar fuori per una pausa sigaretta accidentale mentre viene riparata? Ho visto accadere questo!

Analisi statiche

Inoltre, cerca le correlazioni tra la scrittura di determinati pattern e il bug che viene attivato più o meno spesso. Se riesci a trovare pattern che attivano il problema più frequentemente (o non attivarlo mai), questi potrebbero indicare il tuo problema.

Prova a creare pattern che attivano il problema ancora più di frequente. Se riesci a trovare un modo per attivare il problema in modo affidabile, sei a metà strada verso una soluzione.

Altre opzioni

Infine, non essere rapido nel dare la colpa all'hardware, ma non pensare mai che sia perfetto. Molte volte sono stato accusato di problemi che si sono rivelati di natura elettrica o meccanica, quindi devi averlo sempre in mente.

Anche se normalmente non è possibile accedere alla macchina, ricordare che alcuni problemi possono essere risolti in modo efficiente sulla macchina. A volte alcuni giorni on-site possono valere settimane via desktop remoto e mesi off-line completamente. Se esaurisci le opzioni off-line, non aver paura di proporre una visita al sito, possono solo dire di no.

Potresti anche voler dare un'occhiata alle domande e alle risposte a Che cosa fai con un heisenbug? e Cosa fare con bug che non ripro? ma questi potrebbero non essere così utili per la tua situazione.

Ho intenzione di fare un suggerimento off-the-wall.

Vai al responsabile della fabbrica e chiedi di vedere i record del monitor della linea elettrica per quello strumento, o quell'area, per i tempi in cui si sono verificati i malfunzionamenti. Chiedigli anche se ci fosse qualche saldatura, o qualsiasi altra attività insolita, intorno a quei tempi.

Diversi decenni fa, mio padre stava passando un brutto momento con un minicomputer che stava andando in crash senza motivo. Hanno chiamato il rappresentante del cliente del produttore.

Il rappresentante è entrato nel loro ufficio, nell'area della fabbrica, e ha collegato un voltmetro al muro, accanto al mini, e poi ha detto "Guarda questo".

Pochi minuti dopo, il voltmetro si abbassò improvvisamente, in modo significativo, quindi tornò indietro. Il rappresentante ha detto "È stato lui a colpire il suo arco di prova. Aspetta un attimo." Poco dopo, il voltmetro si abbassò di nuovo e questa volta rimase abbassato.

Il rappresentante ha detto "Questo è il tuo problema: hai un ragazzo che salda sul pavimento della fabbrica, e ha la stessa gamba di potere che hai tu. L'ho visto mentre entravo."

Dovevano eseguire un alimentatore completamente separato per l'ufficio.

Il problema è reale, con conseguenze reali per l'utente, cioè il lavoro rovinato, ecc., quindi è necessario ripararlo. Tuttavia, non deve essere corretto "correttamente". Si dichiara:

A pause and continue operation will again make it to run smoothly with the bug reappearing.

In tal caso, fallo. Il cliente sarà felice di non sprecare materiale su tirature difettose, anche se le corse normali impiegano un paio di secondi in più.

Ovviamente a lungo termine potrebbe essere necessario correggere questo "correttamente" ma per il momento ridurre le perdite del tuo , andare con la soluzione alternativa e passare a qualcos'altro.

Ho avuto un bug in un gioco che è successo solo 1 volta in un miliardo. Fortunatamente questo significava che lo vedevo ogni 15 o 30 minuti, ma passare il codice nel debugger non funzionava. Ho finito per inserire messaggi di debug. Avevano bisogno di usare fantasiose dichiarazioni if perché volevo qualcosa solo quando c'era un problema. Nella maggior parte dei casi il codice di debug stava ripetendo calcoli nel codice normale ma usando tecniche diverse. Le ripetizioni non dovevano essere precise. Se sapessi che un numero dovrebbe essere sempre sotto i 10.000 e in alcune occasioni mi è sembrato di colpire 150.000, avrei controllato solo per un valore superiore a 100.000. Ogni volta che si verificava il bug, studiavo i miei risultati, escogivo messaggi di debug più elaborati (o più precisamente, controlli più elaborati per vedere se dovevo visualizzare un messaggio), e aspetto che il problema si ripresenti.

I tuoi cicli saranno molto più lunghi dei miei, ma alla fine dovrai risolvere il problema. Spero che tu possa trovare la soluzione con qualche altro metodo più veloce, ma questo alla fine se lo farà, se non altro, ti darà la sensazione che stai facendo qualcosa finché non ti viene in mente un migliore idea.

(Nel caso sia utile, ho finalmente risolto il mio problema ripulendo le poche righe di codice che ho finalmente identificato come problema. Giuro che non c'era niente di sbagliato in loro, ma penso che sia l'ottimizzatore sia la CPU fossero istruzioni di riordino per le prestazioni, e penso che una volta ogni tanto stavano prendendo rischi per ottenere un po 'di velocità in più. Anche un singolo core multi-processi in questi giorni, e penso ogni grande una volta in aa mentre un registro veniva letto prima che fosse Ho modificato tutti i calcoli per lavorare con le variabili locali. I valori di "Campo di istanza" sono stati spostati su variabili locali all'inizio e i valori locali sono stati spostati indietro solo alla fine, all'interno dei blocchi di sincronizzazione. em> local valore per il valore di ritorno del metodo piuttosto che il "campo dell'istanza" che stavo usando.)

Regola 1 numero uno nel debug: hai bisogno di uno scenario riproducibile .

Se non ne hai uno, dovresti prima lavorarci su. Riesci a riprodurre quell'errore in una sorta di "modalità di simulazione" della macchina, in cui non viene effettivamente tagliato alcun metallo? Questo sembra avere senso qui. È possibile eseguire diversi programmi di taglio in modo rapido e automatico, simulando il processo di 20 giorni in pochi minuti? Ciò potrebbe aumentare la probabilità che il problema si presenti.

Quindi, quando hai uno scenario del genere, il passo successivo è raccogliere quante più informazioni possibili e avviare effettivamente il debugging.

Non sono sicuro di quale lingua venga eseguita, ma se riscontro bug erratici nel mio codice (C ++), userò uno strumento come valgrind o cppcheck per garantire che nulla vada in memoria.

Un'estensione sulla risposta di RalphChapin:

Nel corso degli anni ho dovuto cercare un buon numero di bug che si sono mostrati solo su sistemi che non potevo duplicare a causa dell'hardware collegato.

Oltre al logging come un matto ho trovato utile un'altra cosa: mettere le informazioni sullo schermo che mostra dove si trovava il codice e i valori di alcune variabili rilevanti. Quando il problema si è manifestato, anche i lavoratori delle fabbriche potevano leggere le informazioni.

Di solito ci sono voluti alcuni giri di raffinamento per fissarlo esattamente ma era molto efficace.