Heisenbug: wat is het, waarom ontstaat het en methodes om het te vangen

Wat is Heisenbug in mobiele ontwikkeling?

Heisenbug — een klasse fouten die verschijnen in de productieomgeving of bij normaal gebruik, maar verdwijnen bij poging tot reproductie in een debugomgeving. De term werd in de jaren 80 geïntroduceerd door programmeur Jim Gray in de context van gedistribueerde systemen, maar is vandaag het meest relevant voor mobiele apps vanwege hun asynchrone aard.

Hoofdoorzaak: standaard debugtools veranderen de uitvoeringsomgeving. Breakpoint stopt de thread voor enkele milliseconden, loggen voegt synchrone I/O toe, extra controles veranderen de volgorde van bewerkingen. In een multi-threaded omgeving kan zelfs een microseconde vertraging de uitvoervolgorde van threads veranderen en een datarace verbergen.

Volgens Microsoft Research (2022) wordt ongeveer 15-25% van alle bugs in multi-threaded mobiele apps geclassificeerd als Heisenbug. De tijd om een Heisenbug te vinden en te repareren is gemiddeld 5-10 keer langer dan voor een gewone bug, vanwege de onmogelijkheid van directe reproductie.

Voorbeeld van Heisenbug

De app crasht in productie bij snel vegen door een lijst, maar wanneer de debugger wordt aangesloten of logs worden toegevoegd, werkt hij perfect. Oorzaak: een datarace tussen de UI-thread (RecyclerView updaten) en de achtergrondthread (adaptergegevens updaten). Logs voegen een vertraging toe die de threads willekeurig synchroniseert.

Bohrbug, Mandelbug, Heisenbug: classificatie van bugs

Bohrbug — een voorspelbare, stabiel reproduceerbare bug. Genoemd naar analogie met het atoommodel van Bohr: zoals een atoom, gedraagt de bug zich bij elke observatie hetzelfde. Voorbeeld: NullPointerException bij klikken op een knop voordat gegevens zijn geladen. Wordt behandeld met standaard unittesten.

Mandelbug — een bug met een complexe, chaotische oorzaak-gevolg relatie (genoemd naar analogie met de Mandelbrot-verzameling). Verschijnt alleen bij een specifieke combinatie van omstandigheden: OS-versie, apparaatmodel, netwerkstatus, maanfase. Verschilt van Heisenbug doordat hij niet verdwijnt bij debuggen — het probleem zit in de moeilijkheid van reproductie, niet in gedragsverandering door tools.

Heisenbug — een bug die juist door debugtools verdwijnt. Als je een log toevoegt — verdwijnt de bug. Als je een breakpoint plaatst — verschijnt de bug niet. Als je alles verwijdert — komt de bug terug. Hoofdoorzaak: veranderde timing tijdens debuggen.

Belangrijkste oorzaken van Heisenbug

Race condition — nummer een onder de oorzaken van Heisenbug. Twee threads krijgen toegang tot gedeelde gegevens zonder synchronisatie. De debugger introduceert een vertraging waardoor de threads de kans krijgen om op natuurlijke wijze te synchroniseren. Zonder debugger is de uitvoervolgorde onvoorspelbaar.

Timing-afhankelijke fouten — bugs die alleen bij een bepaalde uitvoersnelheid verschijnen. Bijvoorbeeld een animatie die moet zijn voltooid voordat de volgende bewerking begint. In de debugger gaat de animatie langzamer en kan de bewerking na de animatie beginnen. In productie — andersom.

// Voorbeeld van race condition — typische Heisenbug
class ListViewModel : ViewModel() {
    private var items = mutableListOf<String>()

    fun loadFromNetwork() {
        viewModelScope.launch(Dispatchers.IO) {
            val result = api.fetchItems()
            items.addAll(result) // ❌ Niet thread-safe
        }
    }

    fun getItems(): List<String> = items.toList()
    // Race condition: getItems lezen kan overlappen met loadFromNetwork schrijven
}

Compileroptimalisatie — de compiler (JIT, ART, Kotlin/Native) kan instructies herordenenen voor optimalisatie. In debug build zijn optimalisaties uitgeschakeld en wordt code uitgevoerd „n zoals geschreven“. In release build verandert de compiler de volgorde van bewerkingen, wat verborgen aannames in de code kan onthullen.

• ThreadLocal — onjuist gebruik van thread-local variabelen die niet zichtbaar zijn voor andere threads
• Niet-geïnitialiseerde variabelen — code die vertrouwt op standaardwaarden van klassevelden
• GCD/dispatch queues — in iOS ongedefinieerde volgorde van blokuitvoering in concurrent queues
• Gebufferde I/O — gegevens worden niet naar schijf geschreven tot de buffer vol is

Strategieën om ongrijpbare bugs te vangen

ThreadSanitizer (TSan) — Google's tool voor detectie van dataraces in C/C++ en Kotlin/Native. Wordt in de build geïntegreerd en detecteert elke toegang tot gedeeld geheugen zonder synchronisatie. In tegenstelling tot logs beïnvloedt TSan de timing niet, omdat het via instrumented code werkt, niet via I/O.

Deterministische tests — vervang echte asynchronie door gecontroleerde. Gebruik TestDispatcher (Kotlin), RxJava Plugins of GCD test queues (iOS) voor volledige controle over de uitvoervolgorde. Stel specifieke scenario's in: thread A wordt uitgevoerd, dan B, dan A opnieuw.

Cyclisch loggen — loggen naar een cyclische buffer in het geheugen (niet naar schijf). Wanneer de bug optreedt, wordt de buffer opgeslagen in een bestand. Omdat schrijven naar geheugen nanoseconden duurt (in plaats van milliseconden voor schijf-I/O), beïnvloedt zo'n log de timing niet en maskeert hij Heisenbug niet.

class CyclicBuffer(val capacity: Int = 1000) {
    private val buffer = ArrayDeque<String>(capacity)
    private val lock = Any()

    fun log(message: String) {
        synchronized(lock) {
            if (buffer.size >= capacity) buffer.removeFirst()
            buffer.addLast(message)
        }
    }

    fun flush() {
        synchronized(lock) { buffer.forEach { fileWriter.write(it) } }
    }
}

Loggen in productie — als de bug zich lokaal niet laat reproduceren, verzamel dan gegevens in productie. Gebruik Firebase Crashlytics logs, Sentry Breadcrumbs of een aangepaste cyclische logger. Belangrijk: loggen moet asynchroon zijn en minimale invloed hebben op prestaties.

Preventie van Heisenbug op architectuurniveau

Isolatie van toestand — minimaliseer gedeelde veranderlijke toestand. Elk component moet zijn eigen geïsoleerde toestand hebben, ontoegankelijk voor direct schrijven vanuit andere componenten. Gebruik Unidirectional Data Flow (UDF) — toestand stroomt in één richting: Event → Reducer → State → UI.

Functionele benadering — pure functies zonder bijwerkingen zijn gemakkelijker te testen en debuggen. Isoleer bijwerkingen (netwerk, database, bestanden) in strikt gedefinieerde lagen (repository, data source). Thread-gerelateerde fouten in functionele code zijn praktisch onmogelijk.

Strict mode — schakel Android StrictMode in debug build in. Het detecteert schendingen van het threadingbeleid (netwerk op main thread, schijf-I/O op main thread) en gooit een uitzondering. Dit verandert een potentiële Heisenbug in een deterministische Bohrbug die direct zichtbaar is.

class DebugApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        if (BuildConfig.DEBUG) {
            StrictMode.setThreadPolicy(
                StrictMode.ThreadPolicy.Builder()
                    .detectDiskReads()
                    .detectDiskWrites()
                    .detectNetwork()
                    .penaltyLog()
                    .build()
            )
        }
    }
}

Code review met focus op asynchronie — verplicht onderdeel van het proces. Elke pull request moet worden gecontroleerd op gedeelde veranderlijke toestand, niet-thread-safe collecties, ontbrekende synchronisatie. Gebruik lint-regels voor automatische verbod op bepaalde patronen (bijv. toegang tot MutableList zonder synchronized).