У сучасній розробці високонавантажених систем навіть найбільш стабільна бібліотека може десятиліттями приховувати критичний дефект. Історія виявлення надрідкісного стану гонитви в GNU libunwind демонструє, наскільки тонкою є межа між бездоганною роботою коду та катастрофічним збоєм. Коли вікно спрацювання помилки становить лише одну процесорну інструкцію, традиційні методи налагодження виявляються безсилими. Розв'язання цієї проблеми зажадало переходу від аналізу поодиноких випадків до масштабного статистичного дослідження даних.
Проблема викрилася в інфраструктурі Rockset — високопродуктивного пошукового рушія на C++, який OpenAI інтегрувала в екосистему ChatGPT для оптимізації роботи з даними та історією переписок. Інженери зіткнулися з феноменом «неможливих» падінь: функції завершувалися некоректно, повертаючи керування за нульовою адресою або зі зміщенням покажчика стека на 8 байтів. У стандартних умовах експлуатації такий код просто не може впасти подібним чином, що перетворило пошук причини на справжній технічний детектив, де кожна робоча гіпотеза розбивалася об факти.
Довгий час команда намагалася використовувати «клінічний» метод налагодження: детальний аналіз одного конкретного дампу пам'яті (core dump) з метою поставити точний діагноз за наявними доказами. Однак цей підхід виявився неефективним, оскільки випадковий характер збоїв приховував загальну закономірність. Перелом настав, коли стратегію змінили на «епідеміологічну». Замість вивчення одного «пацієнта» інженери вирішили проаналізувати всю популяцію крашів за рік. Для автоматизації цього процесу — завантаження та розмітки величезного масиву дампів пам'яті — було використано ChatGPT, який написав відповідний скрипт.
Статистичний аналіз миттєво виявив, що під маскою одного багу ховалися два абсолютно різні явища. Першим виявився рідкісний апаратний збій на одному з хостів Azure, де процесор допускав помилку при читанні даних. Другим же стала глибоко запрятана гонка потоків (race condition) у GNU libunwind — одній із базових бібліотек для розгортання стека (stack unwinding).
Технічна суть проблеми сягає 2007–2008 років, коли в libunwind була реалізована підтримка винятків C++ для архітектури x86_64. Механізм розгортання стека необхідний рантайму C++ для відновлення регістрів і очищення ресурсів при виникненні винятку. У процесі цієї операції бібліотека оновлює покажчик стека, і рівно на одну процесорну інструкцію — часовий інтервал приблизно в 100 пікосекунд — структура з адресою повернення опиняється поза зоною, яку ядро операційної системи гарантує залишити недоторканою.
Якщо саме в цей мікроскопічний проміжок потрапляє системний сигнал, ядро перезаписує область пам'яті, і адреса повернення перетворюється на NULL. Помилка залишалася непоміченою майже два десятиліття, оскільки для її прояву був потрібен збіг унікальних чинників. У випадку з Rockset було створено «ідеальне середовище»: екстремально висока частота генерації винятків, інтенсивний потік системних сигналів та нещодавні зміни в обробнику сигналів, що збільшили споживання стека. Ці умови вивели баг із площини теоретичної можливості в площину щоденних збоїв.
Для усунення проблеми OpenAI перевела свої системи на механізм розгортання стека з libgcc, а в GNU libunwind було надіслано відтворюваний приклад і відповідний патч. Цей кейс підкреслює фундаментальний висновок: у складних розподілених системах якісні дані важливіші за інтуїцію чи осяяння. Коли розрізнені симптоми були об'єднані в єдиний масив даних, пошук причини перетворився з нескінченного перебору гіпотез на просту задачу з пошуку кореляцій.
Цифрова незалежність з оновленням Immich 3.0
