In informatica , un bug ( pronunciato in francese: / b œ g / ) o bug è un difetto di progettazione in un programma per computer che causa un malfunzionamento .
La gravità del malfunzionamento può variare da lieve, ad esempio che causa piccoli errori di visualizzazione - in questo caso si parlerà a volte di " glitch (i) " - a gravi, come un crash del sistema che può portare a gravi incidenti, per esempio. la distruzione in volo del primo razzo Ariane 5 nel 1996 .
Un bug può risiedere in un'applicazione , nel software di terze parti utilizzato da questa applicazione, o anche nel firmware di un componente hardware come nel caso del bug della divisione Pentium . Una patch è un pezzo di software destinato a correggere uno o più bug.
I bug sono una delle cause del malfunzionamento dei dispositivi informatici; altre cause di malfunzionamento includono:
La parola inglese bug appartiene al gergo degli ingegneri hardware e rappresenta i problemi che sono sorti in esso. L'uso del termine per descrivere i guasti nei sistemi meccanici risale almeno a prima degli anni '70 dell'Ottocento . Thomas Edison , tra gli altri, ha usato la parola nei suoi appunti.
Il termine "bug" è indicato nel dizionario online Larousse con la definizione: "Difetto di progettazione o produzione di un programma per computer, che si manifesta in anomalie di funzionamento del computer. "
Il tesoro informatizzato della lingua francese conserva solo la parola "insetto" nel significato di "busta piccante di castagne, faggiole, nocciole e alcuni semi di legumi".
Il sito FranceTerme , l' Ufficio québécois de la langue française e la Direction de la langue française (Belgio) raccomandano il termine "bug" così come i derivati debug, debug e debugger
Il termine a volte è erroneamente attribuito a Grace Hopper . Ha annotato nel suo diario di manutenzione, conservato presso la Smithsonian Institution , datato9 settembre 1947, 15 h 45 , due contatti di un relè hanno causato il malfunzionamento dell'Harvard Mark II , uno dei primi computer elettromeccanici.
Hopper non ha trovato l'insetto, come ha prontamente ammesso. Gli operatori che in seguito lo trovarono, incluso William "Bill" Burke del Naval Weapons Lab conoscevano il termine ingegneria e si divertivano, mantenevano il bug con l'annotazione "primo vero bug trovato" ".
Era un termine usato dagli ingegneri meccanici ed elettrici, per spiegare le difficoltà incontrate nelle apparecchiature, molto prima che Grace Hopper sentisse parlare della parola.
Nel suo libro pubblicato nel 1987, Frederick Brooks afferma che la presenza di bug nel software non è casuale ma è dovuta alla natura stessa del software, in altre parole, ci sono bug nel software perché sono software. Ha anche detto che non esiste un proiettile d'argento - uno strumento miracoloso - per trattare gli insetti, alludendo a una leggenda del Medioevo secondo cui solo una palla in argento , che ricorda il colore della luna, può scongiurare il lupo mannaro .
Il software è un prodotto invisibile e immateriale, la sua modifica non richiede materie prime. La rapidissima evoluzione del mercato IT genera una forte richiesta di cambiamento. Tutti questi fattori rendono le modifiche al software molto più frequenti rispetto ad altri prodotti come automobili o edifici .
I computer sono tra i prodotti più complessi che l'uomo abbia realizzato, e quindi hanno un numero molto elevato di stati . Il software è più complesso dei computer e, a differenza di un'automobile, nessuna parte è uguale. Il rispetto di molti standard , caratteristici dei settori vicini alle telecomunicazioni , ne aumenta la complessità. Il software è inoltre prodotto invisibile, che non può essere rappresentato in uno spazio geometrico, le rappresentazioni grafiche del software comprendono spesso due, anche tre o quattro diagrammi che corrispondono ciascuno a una realtà diversa.
I bug possono indurre il software a tentare di eseguire operazioni che non possono essere eseguite ( eccezioni ): divisione per zero, ricerca di informazioni inesistenti. Queste operazioni - che non vengono mai utilizzate durante il corretto funzionamento del software - innescano un meccanismo sia hardware che software che poi disattiva il software difettoso, provocando un crash del computer o un Denial of Service .
Un watchdog è un dispositivo elettronico autonomo utilizzato per rilevare malfunzionamenti. Questo meccanismo viene spesso utilizzato con sistemi critici e computer industriali .
La schermata blu della morte è il linguaggio popolare del messaggio di disattivazione dei sistemi operativi Microsoft Windows , che viene visualizzato quando viene rilevata un'eccezione nel nucleo del sistema operativo. Il panico del kernel è il messaggio visualizzato in condizioni simili sui sistemi operativi UNIX .
Una perdita di memoria è un malfunzionamento causato da un bug nelle operazioni di allocazione della memoria . Con questo malfunzionamento, la quantità di memoria utilizzata dal software guasto aumenterà continuamente. Se il software difettoso riesce a utilizzare quasi tutta la memoria disponibile, interferisce con l'avanzamento di altri software e ne causa il malfunzionamento.
Un errore di segmentazione è un malfunzionamento dovuto a un bug nelle operazioni di manipolazione dei puntatori o degli indirizzi di memoria . Il software difettoso tenterà di leggere o scrivere informazioni in una posizione di memoria ( segmento ) che non esiste o che non è autorizzata per questo. Il meccanismo di rilevamento delle eccezioni provoca quindi la disattivazione del software difettoso.
Un integer overflow è un malfunzionamento dovuto a un bug nelle operazioni di calcolo matematico. Il software difettoso tenterà di eseguire un calcolo il cui risultato è maggiore del valore massimo autorizzato. Il meccanismo di rilevamento delle eccezioni determina quindi la disattivazione del software difettoso.
Un buffer overflow è un malfunzionamento dovuto a un bug. Un software che deve scrivere informazioni in una posizione di memoria determinata e limitata ( memoria buffer ) supera i limiti di questa posizione e quindi scriverà informazioni su una posizione destinata ad un altro uso, questa modifica inaspettata porta a un'esecuzione irregolare del software, che può terminare con un errore di segmentazione o un overflow. È una vulnerabilità di sicurezza del server comune che viene spesso sfruttata dagli hacker . vedi Exploit .
Uno stack overflow è un malfunzionamento in cui la dimensione dello stack di esecuzione di un software supera la capacità del buffer che lo contiene, causando malfunzionamenti simili a un buffer overflow . Lo stack di esecuzione è una struttura dati immagazzinata in memoria che contiene lo stato degli automatismi software (vedi processo (elaborazione dati) ), questa struttura è registrata in una memoria buffer la cui dimensione è sovradimensionata. Un overflow dello stack risulta da una sequenza errata a causa di un bug.
Una situazione competitiva ( condizione di gara inglese ) è un malfunzionamento dovuto a un bug, che fa sì che due automazioni software in una funzionanti simultaneamente danno risultati diversi a seconda dell'automazione che termina prima dell'altra.
Una situazione di stallo (inglese deadlock ) è quando un malfunzionamento in cui molti si aspettano di automazione tra loro, vale a dire che ogni aspettano le altre uscite le risorse che utilizza per continuare. Le risorse rimangono bloccate durante le attese, il che può bloccare altri automatismi e per effetto domino bloccare l'intero sistema. Un meccanismo di prevenzione provoca l'annullamento dell'operazione quando il tempo di attesa supera il timeout ammissibile .
Più complesso è il codice, più difficile è individuare un bug. I bug che dipendono da una combinazione di condizioni impreviste e improbabili sono particolarmente difficili da individuare. Nel folklore degli hacker ci sono categorie di insetti bizzarri i cui nomi umoristici derivano da quelli di eminenti scienziati in fisica e matematica quantistica.
L'esecuzione passo dopo passo del software utilizzando un debugger può causare Heisenbug semplicemente perché il software è più lento. E le situazioni competitive possono portare a Mandelbug , dove il comportamento del programma è diverso ogni volta che viene eseguito.
I bug sono il risultato di errori umani durante il lavoro di specifica , progettazione , programmazione e test di software e hardware per computer. La crescente complessità del software, i problemi di comunicazione, la mancanza di formazione degli ingegneri e la pressione delle scadenze e dei costi durante il lavoro di ingegneria sono fattori che tendono ad aumentare il numero di bug.
Il test del software è il primo passo per contrastare i bug. Per motivi pratici (costo del lavoro e scadenze), non è possibile testare un software in tutte le condizioni che potrebbe incontrare durante il suo utilizzo e quindi non è possibile contrastare tutti i bug: software come Microsoft Word ha 850 comandi e 1.600 funzioni , per un totale di oltre 500 milioni di condizioni da testare.
L'uso di linguaggi di programmazione di alto livello , che facilitano il lavoro dell'ingegnere. L'implementazione delle convenzioni di scrittura sono altre tecniche preventive intese a diminuire il numero di bug.
Il debug è l'attività di diagnosi e correzione di bug. Durante il debug in linea , l'ingegnere esegue il software passo dopo passo e dopo ogni passaggio esegue una serie di controlli. Durante il debug post mortem , l'ingegnere esamina il software in seguito a un crash del computer.
Quando il bug viene rilevato e corretto dopo che il software è stato distribuito, il fornitore spesso fornisce una patch , cioè un kit che sostituisce le parti difettose del software con quelle che sono state corrette.
Gli ingegneri utilizzano spesso un sistema di tracciamento dei bug , ovvero un software di database in cui vengono inseriti i vari bug e il lavoro svolto per ciascuno:
Molti linguaggi di programmazione includono meccanismi per il controllo dei malfunzionamenti. Le istruzioni necessarie per le verifiche vengono aggiunte automaticamente al codice macchina o al bytecode del software in fase di compilazione . Le istruzioni possono causare l'attivazione automatica del debugger , il software di diagnostica dei bug.
La revisione del codice consiste nel sottoporre il codice sorgente appena sviluppato a una terza persona che lo leggerà di nuovo e cercherà i difetti.
Il test del software è il primo passo per affrontare i bug. Consistono nell'utilizzo del software nel maggior numero di condizioni possibili. Lo scopo dei test è rilevare diversi problemi:
I test vengono ripetuti più volte, come la programmazione avanzata e le correzioni, al fine di validare le correzioni e rilevare eventuali bug di regressione : bug verificatosi a seguito dell'errata correzione di un altro bug. Il test può essere automatizzato utilizzando un software che agisce per conto dell'utente. A volte viene sviluppato un secondo software da utilizzare per i test.
Il test unitario consiste nell'utilizzare una caratteristica unica del software al fine di rilevare i malfunzionamenti. I test di integrazione includono l'utilizzo di una serie di funzioni per il controllo della coerenza dell'insieme. I test di validazione consistono nell'utilizzo di tutto il software al fine di valutarne l'idoneità alle esigenze dell'acquirente.
I test unitari e di integrazione vengono generalmente eseguiti dall'ingegnere, mentre i test di convalida vengono generalmente eseguiti dall'acquirente o dal suo rappresentante.
Un'altra misura preventiva per evitare bug è la prova formale (o dimostrazione matematica) del funzionamento del programma, in modo generico. A differenza del test che verifica solo un dato caso operativo, questa prova cerca di garantire che il programma funzioni in tutti i casi, qualunque siano le condizioni di utilizzo. Ma tutte le tecniche di verifica formale sono macchinose e complesse. In termini assoluti, non sappiamo come verificare il corretto funzionamento di alcun programma in tutti i casi. Dall'altro ci sono metodi di creazione del software, che, durante la creazione del software, impostano elementi per monitorare il passaggio ad ogni passaggio intermedio tra le specifiche o le specifiche del software da un lato, e il programma finale dal l'altra mano. Grazie a questi elementi di monitoraggio, le verifiche sono quindi possibili e possono essere imposti e bloccati vincoli di conformità alle specifiche.
Nei campi in cui un bug causerebbe la morte di esseri umani, (ad esempio in aeronautica), vengono utilizzati metodi ingombranti e complessi per dimostrare l'assenza di bug nel software, durante la sua progettazione. Così, il software di controllo per la linea metropolitana automatica 14 di Parigi è stato originariamente prodotto con la notazione di Z . Tuttavia, il metodo B è stato utilizzato per creare la versione finale. Il metodo B è anche considerato lo strumento migliore per garantire che un programma per computer soddisfi le specifiche del suo comportamento. Infatti, l'utilizzo del Metodo B per creare il programma porta (automaticamente) anche a dimostrare matematicamente la conformità del programma così creato, che diventa quindi per definizione un teorema dimostrato.
Tuttavia, la complessità dell'utilizzo di questo metodo si traduce in un lavoro così extra che un singolo programmatore potrebbe impiegare 100 volte più tempo per creare un programma con questo metodo rispetto a se avesse creato lo stesso programma in modo tradizionale. Ciò significa quindi che costa 100 volte di più creare il programma con questo metodo. Di conseguenza, nonostante la sua efficacia, questo metodo è usato solo molto raramente, e ci sono molte aree in cui i bug possono causare la morte umana e dove creiamo semplicemente programmi pieni di bug., Nel modo tradizionale, e poi eseguiamo test molto rigorosi per eliminarne la maggior parte. Finché la probabilità che un bug crei un malfunzionamento che uccide le persone rimane inferiore alla probabilità che un errore umano crei lo stesso tipo di malfunzionamento, è spesso considerato "accettabile". (E il costo aggiuntivo dell'utilizzo del Metodo B per garantire che nessuno muoia è ritenuto inaccettabile).
Per il debug o la ricerca e la correzione dei bug, gli ingegneri utilizzano il software, il debugger e un sistema di tracciamento dei bug .
Il sistema di bug tracking viene utilizzato per coordinare il lavoro di debugging, è utilizzato per raccogliere tutti i malfunzionamenti osservati, registrare le cause e le azioni correttive effettuate e monitorare così lo stato di avanzamento delle correzioni. Le cause possono essere bug, ma anche guasti nei parametri di configurazione o errori di gestione. Il sistema di tracciamento dei bug viene utilizzato dagli utenti del software difettoso, nonché da ingegneri o amministratori di sistema .
Il debugger permette di analizzare lo stato di esecuzione di un software in un dato momento, le operazioni in corso, le informazioni in memoria, i file aperti, ecc. Con un debugger online , è possibile sospendere l'esecuzione del software in qualsiasi momento, analizzare lo stato e quindi continuare l'elaborazione.
Con un debugger post mortem , è possibile analizzare lo stato di esecuzione del software dopo un crash. L'analisi viene effettuata sulla base di un file che contiene la copia del contenuto della memoria al momento del crash. File chiamato core dump sui sistemi operativi Unix .
Una versione software è lo stato del software in una determinata data, comprese tutte le correzioni e i miglioramenti apportati fino a quella data. La versione si dice alpha o beta quando corrisponde allo stato del software prima della fine della durata dei test. È probabile che una tale versione contenga bug che nel frattempo sono stati rilevati e corretti.
Una volta corretti uno o più difetti, vengono raggruppati in una patch , un kit che contiene solo i componenti software che sono stati corretti. Verrà utilizzato da chiunque possieda una copia del software per applicarvi le correzioni e abbinarlo a una particolare versione.
Il fallimento del volo inaugurale del razzo Ariane 5 nel 1996 è stato causato da un difetto nei dispositivi avionici del razzo, dispositivi utilizzati con successo per diversi anni sul razzo Ariane 4 . Durante il decollo, il dispositivo informatico che ha calcolato la posizione del razzo in base alla sua accelerazione non ha supportato le accelerazioni di Ariane 5, 5 volte più forti di quelle di Ariane 4. Un overshoot intero ha causato il crash del computer del dispositivo. Accecato, l'autopilota ha perso il controllo del razzo e un dispositivo di sicurezza ha causato l'autodistruzione pochi secondi dopo il decollo. È uno dei bug informatici più costosi della storia.
Nel 1962, la missione Mariner 1 subì un incidente simile.
Negli anni '80, un bug che interessava il software di una macchina per radioterapia pilotata da un PDP-11 , il Therac-25 , ebbe conseguenze tragiche, i pazienti ricevettero dosi massicce di radiazioni e almeno cinque morirono.
Il bug dell'anno 2000 , chiamato anche bug del millennio : uno o più bug nel software che manipola le date causano malfunzionamenti quando le date sono successive al 31 dicembre 1999. Una delle cause è che i calcoli sono stati eseguiti sulle date. Solo all'ultimo due cifre dell'anno.
I potenziali problemi posti dalla data del 31 dicembre 1999 sono stati prima anticipato da Bob Berner nel 1971. Hanno provocato una notevole mobilitazione di ingegneria del software aziende a qualche anno prima della scadenza e il costo totale del controllo e controllo del lavoro. Manutenzione preventiva è stimato in oltre $ 600 milioni.
Nel 2002, il sistema informatico del St Mary's Mercy Hospital nel Michigan dichiarò erroneamente la morte di 8.500 pazienti che erano in realtà ancora vivi, inviando alle loro case un conto e una dichiarazione di morte, insieme a un annuncio della loro morte alla loro compagnia di assicurazioni e Sicurezza sociale degli Stati Uniti. Ci vollero diverse settimane perché queste morti venissero cancellate con le varie amministrazioni.
Un bug può essere:
Una specifica può essere informale e vaga (come: "il softwareèun elaboratore di testi che non causa errori di runtime"), o formale e precisa ("sort ( t ) è una permutazione di t come sort ( t ) è ordinato per la relazione <»), fino ad ottenere formule matematiche. Assumendo la specifica più completa possibile, un programma difettoso è quello la cui implementazione non soddisfa tale specifica.
È discutibile se esistono metodi universali, impeccabili e automatici che è necessario seguire solo per rendersi conto se un programma è difettoso o meno. La risposta è no. Infatti, se un tale metodo esistesse, sarebbe possibile automatizzarlo da un computer, cioè da un software di analisi. Questo analizzatore dovrebbe operare su qualsiasi programma da analizzare e dovrebbe, ad esempio, rispondere alla seguente domanda: "lo stato finale del programma può essere uno stato di errore in fase di esecuzione, o è necessariamente uno stato?" Corretto (o non risoluzione) ". Tuttavia, il teorema di Rice afferma che questa domanda non può essere risolta in un sistema di stati infiniti. Più in generale, qualsiasi domanda di specifica relativa allo stato finale del programma è indecidibile , vale a dire che un software o un metodo automatico non può rispondere, tranne per le domande per le quali la risposta è sempre vera o sempre vera falsa.
Si potrebbe obiettare che i computer sono sistemi a stati finiti: ogni computer ha una quantità di memoria finita. Tuttavia, ad eccezione dei sistemi molto piccoli, i computer dovrebbero essere considerati per l'analisi come sistemi di memoria illimitata. In effetti, le tecniche di analisi che utilizzano la finitezza dello stato vanno tutte, in modo più o meno indiretto o ottimizzato, a cercare di enumerare gli stati del sistema. Un sistema con n bit di memoria ha 2 n stati; in un personal computer corrente, n è dell'ordine di 238 . Possiamo quindi vedere che qualsiasi tentativo di elencare gli stati del sistema è destinato al fallimento.
L'impossibilità della ricerca automatica universale dei bug è quindi un problema fondamentale, e non un limite della tecnologia attuale.
L'industria dello sviluppo software fa di tutto per trovare metodi per prevenire gli errori del programmatore che portano a bug.
Trovare e correggere i bug, o il debug , è una parte importante del software di programmazione . Il pioniere del computer Maurice Vincent Wilkes descrive i suoi successi negli anni '40 dicendo che la maggior parte del resto della sua vita sarebbe stata spesa a correggere gli errori nei suoi programmi. Man mano che i programmi per computer diventano sempre più complessi, i bug diventano più frequenti e difficili da correggere. A volte i programmatori dedicano più tempo e fatica a trovare e correggere bug che a scrivere nuovo codice.
Di solito la parte più difficile del debug è trovare la parte del codice responsabile dell'errore. Una volta individuato, correggerlo è spesso facile. Esistono programmi chiamati debugger per aiutare i programmatori a trovare i bug. Tuttavia, anche con l'aiuto di un debugger , trovare un bug è spesso un compito molto difficile.
Di solito, il primo passo per trovare un bug è trovare un modo per riprodurlo facilmente. Una volta che il bug si è riprodotto, il programmatore può utilizzare il debugger o un altro strumento per osservare l'esecuzione del programma nel suo contesto abituale, ed eventualmente trovare il problema. D'altra parte, non è sempre facile riprodurre un bug. Alcuni sono causati dall'input al software che potrebbe essere difficile da riprodurre per il programmatore. Altri potrebbero scomparire quando il programma viene avviato in un debugger ; questi sono chiamati heisenbug (scherzosamente riferendosi al di Heisenberg incertezza linea di principio). Infine, i bug dei programmi paralleli (composti da più moduli in esecuzione contemporaneamente, ad esempio su più processori) sono spesso difficili da riprodurre se dipendono dalla precisa schedulazione dei calcoli sulla macchina.
Il termine bug nei videogiochi ha per significato primario un errore nel presunto corso di un'azione. Il risultato finale del bug non causerà lo stesso disagio a seconda della sua intensità. La mano di un giocatore che sfonda un muro in un FPS non avrà lo stesso fastidio dell'incapacità di completare la missione principale di un gioco di ruolo .
L'esistenza di bug non porta solo punti negativi:
Il termine bug comprende altri concetti meno utilizzati a causa della popolarità del nome bug . Sarebbe saggio nominare alcuni errori "dimenticando" piuttosto che per bug.
Vedi anche la categoria Sviluppo software