Heisenbug: какво е, защо възниква и методи за улавяне

Какво е Heisenbug в мобилното разработване?

Heisenbug — клас грешки, които се проявяват в продукционна среда или при нормална работа, но изчезват при опит за възпроизвеждане в дебъг среда. Терминът е въведен през 80-те години на XX век от програмиста Джим Грей в контекста на разпределени системи, но днес е най-актуален за мобилни приложения поради тяхната асинхронна природа.

Основна причина: стандартните инструменти за дебъгване променят средата на изпълнение. Брейкпойнтът спира нишката за няколко милисекунди, логирането добавя синхронен I/O, допълнителните проверки променят реда на операциите. В многонишкова среда дори микросекундно закъснение може да промени реда на изпълнение на нишките и да скрие състезание на данни.

Според данни на Microsoft Research (2022), около 15-25% от всички бъгове в многонишкови мобилни приложения се класифицират като Heisenbug. Времето за намиране и поправяне на един Heisenbug е средно 5-10 пъти по-голямо от обикновен бъг, поради невъзможността за директно възпроизвеждане.

Пример за Heisenbug

Приложението се срива в продукция при бързо превъртане на списъка, но при свързване на дебъгер или добавяне на логове — работи перфектно. Причина: състезание на данни между UI нишката (актуализиране на RecyclerView) и фоновата нишка (актуализиране на данните на адаптера). Логовете добавят закъснение, което случайно синхронизира нишките.

Bohrbug, Mandelbug, Heisenbug: класификация на бъгове

Bohrbug — предвидим, стабилно възпроизводим бъг. Наречен по аналогия с атомния модел на Бор: като атом, бъгът се държи еднакво при всяко наблюдение. Пример: NullPointerException при кликване на бутон преди зареждане на данни. Лекува се със стандартно unit тестване.

Mandelbug — бъг със сложна, хаотична причинно-следствена връзка (наречен по аналогия с множеството на Манделброт). Проявява се само при определена комбинация от условия: версия на ОС, модел устройство, състояние на мрежата, фаза на луната. Различава се от Heisenbug по това, че не изчезва при дебъгване — проблемът е в трудността на възпроизвеждане, а не в промяна на поведението от инструментите.

Heisenbug — бъг, който изчезва именно поради инструментите за дебъгване. Ако добавите лог — бъгът изчезва. Ако поставите брейкпойнт — бъгът не се проявява. Ако махнете всичко — бъгът се връща. Основна причина: променен timing при дебъгване.

Основни причини за възникване на Heisenbug

Race condition — номер едно сред причините за Heisenbug. Две нишки достъпват общи данни без синхронизация. Дебъгерът внася закъснение, благодарение на което нишките успяват да се синхронизират естествено. Без дебъгер редът на изпълнение е непредвидим.

Грешки, зависещи от timing — бъгове, които се проявяват само при определена скорост на изпълнение. Например анимация, която трябва да завърши преди началото на следващата операция. В дебъгера анимацията е по-бавна и операцията успява да започне след завършването на анимацията. В продукция — обратно.

// Пример за race condition — типичен Heisenbug
class ListViewModel : ViewModel() {
    private var items = mutableListOf<String>()

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

    fun getItems(): List<String> = items.toList()
    // Race condition: четенето на getItems може да се припокрие с писането на loadFromNetwork
}

Оптимизация на компилатора — компилаторът (JIT, ART, Kotlin/Native) може да пренареди инструкции за оптимизация. В debug build оптимизациите са изключени и кодът се изпълнява „както е написан“. В release build компилаторът променя реда на операциите, което може да разкрие скрити предположения в кода.

• ThreadLocal — неправилно използване на thread-local променливи, които не са видими за други нишки
• Неинициализирани променливи — код, разчитащ на стойностите по подразбиране на полетата на класа
• Опашки GCD/dispatch — в iOS неопределен ред на изпълнение на блокове в concurrent опашки
• Буфериран I/O — данните не се записват на диск, докато буферът не се напълни

Стратегии за улавяне на неуловими бъгове

ThreadSanitizer (TSan) — инструмент на Google за откриване на състезания на данни в C/C++ и Kotlin/Native. Вгражда се в build-а и детектира всеки достъп до споделена памет без синхронизация. За разлика от логовете, TSan не влияе на timing-а, защото работи чрез instrumented code, а не чрез I/O.

Детерминистични тестове — заменете реалната асинхронност с контролирана. Използвайте TestDispatcher (Kotlin), RxJava Plugins или GCD test queues (iOS) за пълен контрол над реда на изпълнение. Задайте конкретни сценарии: нишка A се изпълнява, после B, после A отново.

Циклично логиране — логиране в цикличен буфер в паметта (не на диск). Когато бъгът се случи, буферът се запазва във файл. Тъй като записът в паметта отнема наносекунди (вместо милисекунди за диск I/O), такъв лог не влияе на timing-а и не маскира 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) } }
    }
}

Логиране в продукция — ако бъгът не се възпроизвежда локално, събирайте данни в продукция. Използвайте Firebase Crashlytics logs, Sentry Breadcrumbs или персонализиран цикличен логер. Важно: логирането трябва да бъде асинхронно и да влияе минимално на производителността.

Профилактика на Heisenbug на ниво архитектура

Изолация на състоянието — минимизирайте споделеното променливо състояние. Всеки компонент трябва да има свое изолирано състояние, недостъпно за директен запис от други компоненти. Използвайте Unidirectional Data Flow (UDF) — състоянието тече в една посока: Event → Reducer → State → UI.

Функционален подход — чисти функции без странични ефекти се тестват и дебъгват по-лесно. Страничните ефекти (мрежа, база данни, файлове) изолирайте в строго определени слоеве (repository, data source). Грешки, свързани с нишки във функционален код, са практически невъзможни.

Strict mode — включете Android StrictMode в debug build. Той детектира нарушения на threading политиката (мрежа на главната нишка, диск I/O на главната нишка) и хвърля изключение. Това превръща потенциалния Heisenbug в детерминистичен Bohrbug, видим веднага.

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

Code review с фокус върху асинхронността — задължителна част от процеса. Всеки pull request трябва да се проверява за споделено променливо състояние, небезопасни за нишки колекции, липса на синхронизация. Използвайте lint правила за автоматично забраняване на определени модели (напр. достъп до MutableList без synchronized).