Heisenbug: ce este, de ce apare și metode de depistare

Ce este Heisenbug în dezvoltarea mobilă?

Heisenbug — o clasă de erori care apar în mediul de producție sau în timpul funcționării normale, dar dispar când se încearcă reproducerea lor în mediul de depanare. Termenul a fost introdus în anii 1980 de programatorul Jim Gray în contextul sistemelor distribuite, dar este cel mai relevant astăzi pentru aplicațiile mobile datorită naturii lor asincrone.

Cauza principală: instrumentele standard de depanare modifică mediul de execuție. Breakpointul oprește firul de execuție pentru câteva milisecunde, logarea adaugă I/O sincron, verificările suplimentare schimbă ordinea operațiilor. Într-un mediu multi-fir, chiar și o întârziere de microsecunde poate schimba ordinea de execuție a firelor și poate ascunde o condiție de cursă.

Conform datelor Microsoft Research (2022), aproximativ 15-25% din toate erorile din aplicațiile mobile multi-fir sunt clasificate ca Heisenbug. Timpul de găsire și remediere a unui Heisenbug este în medie de 5-10 ori mai mare decât pentru o eroare obișnuită, din cauza imposibilității reproducerii directe.

Exemplu de Heisenbug

Aplicația se prăbușește în producție la o glisare rapidă a listei, dar când este conectată la debugger sau când se adaugă loguri, funcționează perfect. Cauza: o condiție de cursă între firul UI (actualizarea RecyclerView) și firul de fundal (actualizarea datelor adaptorului). Logurile adaugă o întârziere care sincronizează firile în mod aleatoriu.

Bohrbug, Mandelbug, Heisenbug: clasificarea erorilor

Bohrbug — o eroare previzibilă, stabil reproducibilă. Denumită prin analogie cu modelul atomic al lui Bohr: ca un atom, eroarea se comportă la fel la fiecare observație. Exemplu: NullPointerException la apăsarea unui buton înainte de încărcarea datelor. Se tratează prin testare unitară standard.

Mandelbug — o eroare cu o relație cauză-efect complexă, haotică (denumită prin analogie cu mulțimea Mandelbrot). Apare doar la o anumită combinație de condiții: versiunea sistemului de operare, modelul dispozitivului, starea rețelei, faza lunii. Se deosebește de Heisenbug prin faptul că nu dispare la depanare — problema constă în dificultatea reproducerii, nu în schimbarea comportamentului din cauza instrumentelor.

Heisenbug — o eroare care dispare tocmai din cauza instrumentelor de depanare. Dacă adaugi un log — eroarea dispare. Dacă pui un breakpoint — eroarea nu apare. Dacă scoți totul — eroarea revine. Cauza principală: timingul modificat în timpul depanării.

Principalele cauze ale apariției Heisenbug

Race condition — numărul unu printre cauzele Heisenbug. Două fire de execuție accesează date comune fără sincronizare. Debuggerul introduce o întârziere datorită căreia firele reușesc să se sincronizeze natural. Fără debugger, ordinea de execuție este imprevizibilă.

Erori dependente de timing — erori care apar doar la o anumită viteză de execuție. De exemplu, o animație care ar trebui să se termine înainte de începerea următoarei operații. În debugger, animația merge mai încet și operația reușește să înceapă după terminarea animației. În producție — invers.

// Exemplu de race condition — Heisenbug tipic
class ListViewModel : ViewModel() {
    private var items = mutableListOf<String>()

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

    fun getItems(): List<String> = items.toList()
    // Race condition: citirea getItems se poate suprapune cu scrierea loadFromNetwork
}

Optimizarea compilatorului — compilatorul (JIT, ART, Kotlin/Native) poate reordona instrucțiunile pentru optimizare. În buildul de depanare (debug build), optimizările sunt dezactivate și codul se execută „așa cum a fost scris“. În release build, compilatorul schimbă ordinea operațiilor, ceea ce poate dezvălui presupuneri ascunse în cod.

• ThreadLocal — utilizarea incorectă a variabilelor thread-local care nu sunt vizibile pentru alte fire
• Variabile neinițializate — cod care se bazează pe valorile implicite ale câmpurilor clasei
• Cozile GCD/dispatch — în iOS, ordinea nedefinită de execuție a blocurilor în cozile concurrent
• I/O bufferizat — datele nu sunt scrise pe disc până când bufferul nu este umplut

Strategii de depistare a erorilor evazive

ThreadSanitizer (TSan) — instrumentul Google pentru detectarea condițiilor de cursă în C/C++ și Kotlin/Native. Se încorporează în build și detectează orice acces la memoria partajată fără sincronizare. Spre deosebire de loguri, TSan nu afectează timingul, deoarece funcționează prin instrumented code, nu prin I/O.

Teste deterministe — înlocuiți asincronicitatea reală cu una controlată. Folosiți TestDispatcher (Kotlin), RxJava Plugins sau GCD test queues (iOS) pentru control complet asupra ordinii de execuție. Stabiliți scenarii specifice: firul A se execută, apoi B, apoi A din nou.

Logare ciclică — logarea într-un buffer ciclic în memorie (nu pe disc). Când apare eroarea, bufferul este salvat într-un fișier. Deoarece scrierea în memorie durează nanosecunde (în loc de milisecunde pentru I/O pe disc), un astfel de log nu afectează timingul și nu maschează Heisenbug.

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) } }
    }
}

Logarea în producție — dacă eroarea nu se reproduce local, colectați date în producție. Folosiți Firebase Crashlytics logs, Sentry Breadcrumbs sau un logger ciclic personalizat. Important: logarea trebuie să fie asincronă și să aibă un impact minim asupra performanței.

Prevenirea Heisenbug la nivel de arhitectură

Izolarea stării — minimizați starea partajată mutabilă. Fiecare componentă trebuie să aibă propria stare izolată, inaccesibilă pentru scriere directă din alte componente. Folosiți Unidirectional Data Flow (UDF) — starea curge într-o singură direcție: Event → Reducer → State → UI.

Abordarea funcțională — funcțiile pure fără efecte secundare sunt mai ușor de testat și depanat. Efectele secundare (rețea, bază de date, fișiere) se izolează în straturi strict definite (repository, data source). Erorile legate de fire în codul funcțional sunt practic imposibile.

Strict mode — activați Android StrictMode în buildul de depanare. Detectează încălcări ale politicii de threading (rețea pe firul principal, I/O pe disc pe firul principal) și aruncă o excepție. Aceasta transformă un potențial Heisenbug într-un Bohrbug determinist, vizibil imediat.

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

Code review cu accent pe asincronicitate — parte obligatorie a procesului. Fiecare pull request trebuie verificat pentru stare partajată mutabilă, colecții nethread-safe, lipsă de sincronizare. Folosiți reguli lint pentru interzicerea automată a anumitor patternuri (de exemplu, accesul la MutableList fără synchronized).