Che cos'è uno schrödinbug?

Questa pagina wiki dice:

Uno schrödinbug è un bug che si manifesta solo dopo che qualcuno ha letto il codice sorgente o utilizzato il programma in modo insolito nota che non avrebbe mai dovuto funzionare in primo luogo, a quel punto il programma smette di funzionare prontamente per tutti fino a quando non viene risolto. Il file Jargon aggiunge: "Anche se ... sembra impossibile, succede; alcuni programmi ospitano schrödinbugs latenti per anni."

Ciò di cui si parla è molto vago ..

Qualcuno può fornire un esempio di come è uno schrödinbug (come in una situazione di fantasia / vita reale)?

Nella mia esperienza lo schema è questo:

• Il sistema funziona, spesso per anni
• È stato segnalato un errore
• Lo sviluppatore indaga sull'errore e trova un po 'di codice che sembra essere completamente difettoso e dichiara che "non avrebbe mai potuto funzionare"
• Il bug viene corretto e cresce la legenda del codice che non avrebbe mai potuto funzionare (ma che ha funzionato per anni)

Siamo logici qui. Codice che non avrebbe mai potuto funzionare ... non avrebbe mai potuto funzionare . Se ha fatto il lavoro, allora l'affermazione è falsa.

Quindi sto per dire che un bug esattamente come descritto (che sta osservando il codice imperfetto smette di funzionare) è palesemente senza senso.

In realtà ciò che è successo è una delle due cose:

1) Lo sviluppatore non ha compreso appieno il codice . In questo caso il codice è di solito un casino e da qualche parte in esso ha una maggiore ma non ovvia sensibilità a una condizione esterna (diciamo una specifica versione o configurazione del sistema operativo che governa il funzionamento di alcune funzioni in modo minore ma significativo). Questa condizione esterna viene modificata (ad esempio da un aggiornamento o modifica del server che si ritiene non sia correlato) e, in tal modo, il codice si rompe.

Lo sviluppatore quindi esamina il codice e, non comprendendo il contesto storico o avendo il tempo di rintracciare ogni possibile dipendenza e scenario, ha dichiarato che non avrebbe mai potuto funzionare e lo riscrive.

In questa situazione, la cosa da capire qui è che l'idea che "non avrebbe mai potuto funzionare" è dimostrabilmente falsa (perché l'ha fatto).

Questo non vuol dire che riscrivere è una cosa negativa - spesso non lo è, mentre è bello sapere esattamente cosa c'era che non andava spesso che richiede tempo e riscrivere la sezione del codice è spesso più veloce e ti permette di essere sicuro di aver corretto le cose.

2) In realtà non ha mai funzionato, nessuno lo ha mai notato . Ciò è sorprendentemente comune, in particolare nei sistemi di grandi dimensioni. In questo caso qualcuno di nuovo inizia e inizia a guardare le cose in un modo in cui nessuno ha mai fatto prima, o un processo aziendale cambia portando un caso marginale in precedenza minore nel processo principale e qualcosa che non ha mai funzionato (o ha funzionato, ma non tutto il tempo) viene trovato e segnalato.

Lo sviluppatore lo guarda e dichiara "non avrebbe mai potuto funzionare" ma gli utenti dicono "sciocchezze, lo usiamo da anni" e hanno ragione, ma qualcosa che considerano irrilevante (e di solito non menzionano fino al sviluppatore trova la condizione precisa a questo punto se ne vanno "oh sì, noi non facciamo che ora e non hanno fatto prima") è cambiato.

Qui lo sviluppatore ha ragione: non avrebbe mai funzionato e mai funzionato.

Ma in entrambi i casi una delle due cose è vera:

• L'affermazione "non avrebbe mai potuto funzionare" è vera e non ha mai funzionato - la gente pensava semplicemente di averlo fatto
• Ha funzionato e l'affermazione "non avrebbe mai potuto funzionare" è falsa e dipende da una (generalmente ragionevole) mancanza di comprensione del codice e delle sue dipendenze

Poiché tutti menzionano un codice che non avrebbe mai dovuto funzionare, ti fornirò un esempio in cui mi sono imbattuto, circa 8 anni fa, in un progetto VB3 morente che veniva convertito in .net. Sfortunatamente il progetto ha dovuto essere aggiornato fino al completamento della versione .net - e sono stato l'unico lì a capire anche da remoto VB3.

C'era una funzione molto importante che veniva chiamata centinaia di volte per ogni calcolo: calcolava l'interesse mensile per i piani pensionistici a lungo termine. Riprodurrò le parti interessanti.

Function CalculateMonthlyInterest([...], IsYearlyInterestMode As Boolean, [...]) As Double
    [about 30 lines of code]
    If IsYearlyInterestMode Then
        [about 30 lines of code]
        If Not IsYearlyInterestMode Then
            [about 30 lines of code (*)]
        End If
    End If
End Function

La parte contrassegnata da una stella aveva il codice più importante; è stata l'unica parte che ha effettuato il calcolo effettivo. Chiaramente questo non avrebbe mai dovuto funzionare, giusto?

Ci sono voluti molti debug, ma alla fine ho trovato la causa: IsYearlyInterestModeera Trueed Not IsYearlyInterestModeera anche vero. Questo perché da qualche parte lungo la linea qualcuno lo ha lanciato su un numero intero, quindi in una funzione che dovrebbe impostarlo su true lo ha incrementato (se è 0 per Falsesarebbe impostato su 1, che è VB True, quindi posso vedere la logica lì), quindi riportalo su un valore booleano. E mi è rimasta una condizione che non può mai accadere e tuttavia accade sempre.

Non conosco un esempio del mondo reale, ma per semplificarlo con una situazione di esempio:

• Un bug non viene notato per un certo periodo, poiché l'applicazione non esegue il codice in condizioni che ne causano il fallimento.
• Qualcuno lo nota facendo qualcosa al di fuori del normale uso (o ispezionando la fonte).
• Ora che il bug viene notato, l'applicazione non riesce anche fino a quando le condizioni normali, fino a quando il bug non viene corretto.

Ciò può accadere perché il bug corromperà alcuni stati dell'applicazione che causano errori nelle condizioni precedentemente normali.

Un esempio di vita reale. Non riesco a mostrare il codice, ma la maggior parte delle persone si collega a questo.

Abbiamo una grande libreria interna di funzioni di utilità in cui lavoro. Un giorno cerco una funzione per fare una cosa particolare e trovo che Frobnicate()provi ad usarla. Uh-oh: si scopre che Frobnicate()restituisce sempre un codice di errore.

Scavando nell'implementazione, trovo alcuni errori logici di base Frobnicate()che lo fanno sempre fallire. Nel controllo del codice sorgente posso vedere che la funzione non è stata modificata da quando è stata scritta, il che significa che la funzione non ha mai funzionato come previsto. Perché nessuno l'ha notato? Cerco il resto della lista di arruolamento della fonte e trovo che tutti i chiamanti esistenti Frobnicate()ignorano il valore di ritorno (e quindi contengono bug sottili propri). Se cambio queste funzioni per controllare il valore restituito come dovrebbero, anche loro iniziano a fallire.

Questo è un caso comune della condizione n. 2 che Jon Hopkins ha menzionato nella sua risposta, ed è deprimentemente comune nelle grandi biblioteche interne.

Ecco un vero Schrödinbug che ho visto in alcuni codici di sistema. Un demone root deve comunicare con un modulo kernel. Quindi il codice del kernel crea alcuni descrittori di file:

int pipeFDs[1];

quindi imposta la comunicazione su una pipe che verrà collegata a una pipe denominata:

int pipeResult = pipe(pipeFDs);

Questo non dovrebbe funzionare. pipe()scrive due descrittori di file nell'array, ma c'è solo spazio per uno. Ma per circa sette anni ha fatto il lavoro; l'array si trovava davanti a uno spazio inutilizzato nella memoria che è stato cooptato in un descrittore di file.

Quindi, un giorno, ho dovuto trasferire il codice su una nuova architettura. Ha smesso di funzionare e il bug che non avrebbe mai dovuto funzionare è stato scoperto.

Un corollario dello Schrödinbug è l' Heisenbug - che descrive un bug che scompare (o appare occasionalmente) quando si tenta di investigare e / o risolverlo.

Gli Heisenbugs sono mitici piccoli e intelligenti furfanti che corrono e si nascondono quando viene caricato un debugger, ma escono dal legno una volta che hai smesso di guardare.

In realtà, questi di solito sembrano essere causati da uno dei seguenti:

• l'impatto di tale ottimizzazione, con cui il codice compilato -DDEBUGè ottimizzato a un livello diverso dalla build di rilascio
• sottili differenze di temporizzazione dovute a bus di comunicazione del mondo reale o interruzioni leggermente diverse dai carichi fittizi "perfetti" simulati

Entrambi evidenziano l'importanza del test del codice di rilascio sull'apparecchiatura di rilascio, nonché del test unità / modulo / sistema mediante emulatori.

Ho visto alcuni Schödinbugs e sempre per lo stesso motivo:

La politica aziendale prevedeva che tutti dovessero utilizzare un programma.
Nessuno lo usava davvero (soprattutto perché non c'era formazione per questo.)
Ma non potevano dirlo alla direzione. Quindi tutti dovevano dire "Uso questo programma da 2 anni e non ho mai riscontrato questo bug fino ad oggi."
Il programma non ha mai funzionato, tranne una minoranza di utenti (inclusi gli sviluppatori che l'hanno scritto).

In un caso, il programma era stato sottoposto a numerosi test, ma non sul database reale (che era considerato troppo sensibile, quindi è stata utilizzata una versione falsa).

Ho un esempio della mia storia, è stato circa 25 anni fa. Ero un bambino a programmare rudimentalmente la grafica in Turbo Pascal. TP aveva una libreria chiamata BGI che includeva alcune funzioni che ti consentivano di copiare una regione dello schermo in un blocco di memoria basato su puntatore, e poi di blitarlo altrove. Combinato con lo xor blitting su uno schermo in bianco e nero, potrebbe essere usato per fare semplici animazioni.

Volevo fare un ulteriore passo avanti e fare sprite. Ho scritto un programma che disegnava grandi blocchi e controlli per colorarli, così come li hai riprodotti come pixel, producendo un semplice programma di disegno per creare sprite, che poteva poi copiare in memoria. C'era solo un problema, per usare questi sprite benedetti, avrebbero dovuto essere salvati in un file in modo che altri programmi potessero leggerli. Ma TP non aveva modo di serializzare l'allocazione di memoria basata su puntatore. I manuali hanno dichiarato chiaramente che non potevano essere scritti su file.

Ho trovato un pezzo di codice che, con successo, ha scritto su un file. E ho iniziato a scrivere un programma di test che ha generato uno sprite dal mio programma di disegno su uno sfondo, mentre andavo verso la creazione di un gioco. E ha funzionato magnificamente. Il giorno successivo, tuttavia, ha smesso di funzionare. Non mostrava altro che un pasticcio confuso. Non ha mai funzionato di nuovo. Ho creato un nuovo sprite, e ha funzionato perfettamente, fino a quando non ha funzionato, ed è stato di nuovo un pasticcio confuso.

Ci è voluto molto tempo ma alla fine ho capito cosa stava succedendo. Il programma di disegno non stava, come pensavo, salvando i dati dei pixel copiati su file - stava salvando il puntatore stesso. Quando il programma successivo ha letto il file, ha finito con un puntatore allo stesso blocco di memoria - che conteneva ancora ciò che l'ultimo programma aveva scritto lì (questo era su MS-DOS, la gestione della memoria era inesistente). Ma ha funzionato ... fino a quando non hai riavviato, o hai eseguito qualsiasi cosa che avesse riutilizzato quella stessa area di memoria, e poi hai avuto un pasticcio confuso perché stavi mandando un mucchio di dati completamente non correlati al blocco di memoria video.

Non avrebbe mai dovuto funzionare, non avrebbe mai nemmeno dovuto funzionare (e su qualsiasi sistema operativo reale non avrebbe funzionato), ma continuava a funzionare e, una volta rotto, è rimasto rotto.

Questo succede sempre quando le persone usano i debugger.

L'ambiente di debug è diverso dall'ambiente di produzione effettivo, senza debugger.

L'esecuzione con un debugger può mascherare cose come gli overflow dello stack perché i frame dello stack del debugger mascherano il bug.

Non ho mai visto un vero schrodinbug e non penso che possano esistere: scoprirlo non romperà le cose.

Piuttosto, qualcosa è cambiato che ha rivelato un insetto che si nascondeva da secoli. Qualunque cosa sia cambiata è ancora cambiata e quindi il bug continua a comparire mentre allo stesso tempo qualcuno trova il bug.