Mandelbug: cos'è, cause di instabilità e metodi di ricerca

Cos'è Mandelbug?

Mandelbug è un bug software con comportamento non lineare e caotico. A differenza di Bohrbug, che si riproduce stabilmente con gli stessi dati di input, Mandelbug può apparire in una sessione ed essere completamente assente in un'altra nelle stesse condizioni esterne.

Il termine è stato introdotto da Jim Gray e Andreas Reuter nel 1993 come parte di una classificazione dei bug software. Mandelbug è stato chiamato così in onore di Benoit Mandelbrot, il matematico che ha scoperto gli insiemi frattali, dove il comportamento del sistema dipende esponenzialmente dalle condizioni iniziali.

Il principale pericolo di Mandelbug risiede nella sua imprevedibilità. Un tester può eseguire lo stesso scenario cinquanta volte, e il bug si manifesterà solo alla cinquantunesima volta — o non si manifesterà affatto. Questo crea una falsa sensazione di stabilità del sistema.

Definizione secondo Gray e Reuter

Secondo la classificazione del libro “Transaction Processing: Concepts and Techniques”, Mandelbug è un difetto che non soddisfa la condizione di determinismo. Il suo comportamento dipende da fattori che lo sviluppatore non può controllare: ordine di scheduling dei thread, frammentazione della memoria, caching.

Origine del nome Mandelbug

Il nome Mandelbug deriva da Benoit Mandelbrot, il matematico che ha introdotto il concetto di frattali e studiato i sistemi caotici. L'insieme di Mandelbrot dimostra una proprietà sorprendente: cambiamenti infinitamente piccoli nelle condizioni iniziali portano a risultati fondamentalmente diversi.

Gray e Reuter hanno tracciato un'analogia diretta: come il frattale di Mandelbrot è sensibile alle condizioni iniziali, Mandelbug è sensibile allo stato del sistema al momento dell'esecuzione. Un cambiamento nell'ordine di allocazione della memoria o nel quanto di scheduling dei thread — e il bug scompare o appare.

Nel gergo professionale, Mandelbug è anche chiamato “bug fantasma” o “bug intermittente”. È il principale nemico degli ingegneri QA poiché non si presta alla metodologia standard “riproduci — segnala — verifica la correzione”.

Caratteristiche di Mandelbug

Mandelbug possiede un insieme unico di proprietà che lo distinguono da tutti gli altri tipi di bug software. Esaminiamo ciascuna di esse.

Non linearità

Il comportamento di Mandelbug è non lineare. Può non manifestarsi migliaia di volte, e poi apparire improvvisamente in condizioni apparentemente identiche. Questa proprietà lo rende praticamente non rilevabile durante i test funzionali.

Dipendenza dallo stato

Mandelbug dipende dallo stato interno del sistema: dimensione dell'heap, ordine di allocazione degli oggetti, occupazione della cache della CPU. Persino l'aggiunta di un printf di debug può modificare i tempi e “guarire” il bug, trasformandolo in Heisenbug.

Effetto farfalla

Il termine “effetto farfalla” si applica pienamente a Mandelbug. Modificare una riga di codice in un modulo completamente diverso può eliminare o, al contrario, causare Mandelbug in una parte non correlata dell'applicazione a causa di cambiamenti nei pattern di allocazione della memoria.

Cause principali di Mandelbug

Le cause di Mandelbug sono legate all'esecuzione concorrente e al comportamento non deterministico dei moderni sistemi informatici.

Race condition

Una condizione di gara classica — quando due thread accedono simultaneamente a una risorsa condivisa senza sincronizzazione. Il risultato dipende da quale thread viene eseguito per primo, e l'ordine di esecuzione non è garantito dal sistema operativo.

Problemi di caching

La cache del processore e la cache del browser possono memorizzare dati obsoleti. Se un'applicazione si basa su un valore memorizzato nella cache che non è più pertinente, si verifica un Mandelbug — un errore che si manifesta solo con cache “fredda” o “calda”.

Comportamento indefinito del compilatore

Alcune costruzioni del linguaggio (ad esempio, variabili non inizializzate in C/C++) portano a un comportamento indefinito. Il compilatore può generare codice diverso a seconda del livello di ottimizzazione, dei flag di compilazione e della versione del compilatore.

Come trovare Mandelbug in un progetto

Trovare Mandelbug richiede un approccio sistematico e strumenti specializzati. I metodi di debug convenzionali non funzionano qui perché il bug non è riproducibile su richiesta.

Logging a tutti i livelli

Il logging dettagliato è l'unico modo per catturare Mandelbug. Ogni thread deve registrare il proprio stato, timestamp e ordine delle operazioni. Dopo un crash, i log vengono analizzati per identificare pattern.

Stress test

I test di carico con operazioni ripetute aumentano la probabilità di manifestazione di Mandelbug. Più iterazioni ci sono, maggiore è la probabilità che una rara combinazione di condizioni porti a un fallimento.

Strumenti specializzati

ThreadSanitizer, Helgrind e altri analizzatori di race condition possono rilevare potenziali Mandelbug senza doverli effettivamente riprodurre. Analizzano il codice staticamente e trovano punti in cui possono verificarsi condizioni di gara.

// Potential Mandelbug: race condition on shared counter
int counter = 0;

void increment() {
    // Two threads may read counter at the same time
    counter++;  // race condition here
}

In questo esempio, Mandelbug può manifestarsi solo in una specifica combinazione di circostanze — quando entrambi i thread chiamano increment() simultaneamente. Nel 99% dei casi, il codice funziona correttamente, creando una falsa sensazione di sicurezza.

Mandelbug vs Heisenbug: qual è la differenza

Gli sviluppatori principianti spesso confondono Mandelbug e Heisenbug. Sebbene entrambi i tipi appartengano a bug instabili, c'è una differenza fondamentale tra loro.

Mandelbug è caotico per natura, mentre Heisenbug è deterministico ma cambia comportamento sotto osservazione. La differenza è importante per scegliere una strategia di debug.

Esempio di Mandelbug nel codice

Esaminiamo un tipico Mandelbug in un'applicazione Android legato a una race condition durante il lavoro con SharedPreferences.

public class UserPreferences {
    private final SharedPreferences prefs;

    public synchronized void updateScore(int delta) {
        int current = prefs.getInt("score", 0);
        current += delta;
        prefs.edit().putInt("score", current).apply();
    }
}

A prima vista, il codice è corretto: il metodo è sincronizzato. Tuttavia, SharedPreferences è un singleton all'interno del processo, e la sincronizzazione non protegge dalle chiamate parallele da thread diversi che hanno ottenuto lo stesso valore di current prima che uno di essi potesse scrivere un nuovo valore. Di conseguenza, un incremento viene perso.

Questo Mandelbug può non manifestarsi per settimane finché due thread non chiamano accidentalmente updateScore simultaneamente con un intervallo di tempo minimo. Dopo il rilevamento, la correzione è banale — utilizzare un'operazione atomica o un database con transazioni.