Как OpenAI нашла 18-летний баг в libunwind через эпидемиологию

OpenAI столкнулась с загадочными крахами в Rockset, облачной системе для поиска и real-time аналитики, которая пополняет индекс знаний ChatGPT при поиске релевантных данных. Крахи казались невозможными: функция вроде бы завершалась нормально, но затем возвращалась на некорректный адрес, или указатель стека был смещён на 8 байт, или сохранённый адрес возврата в стеке был NULL.

Первый подход был традиционным: инспектировали несколько core dump'ов, выдвигали гипотезы, исключали их. Большинство крахей происходили в методе DocumentTree::updateDocument, но спектр возможных причин был огромен (компилятор, бібліотеки, ядро Linux, стреющий запись в неправильную память, всё казалось маловероятным).

Перелом наступил, когда команда переключилась на эпидемиологический подход: вместо анализа одного случая они построили pipeline для автоматического разбора ВСЕХ core dump'ов Rockset за предыдущий год. ChatGPT помог написать скрипт, который скачивал фрагменты файлов, извлекал регистры, фильтровал известные false positives и классифицировал крахи по типам (return-to-null, misaligned-stack, other).

Данные раскрыли правду: это были ДВЕ независимые проблемы, а не одна.

Return-to-null краши: были распределены по разным регионам и инфраструктуре, участились недавно, но без чёткой даты начала.
Misaligned-stack краши: все пришли из одного региона, имели чёткую дату начала, не происходили на давно работающих хостах. Анализ Kubernetes nodes и временных меток указал на один физический хост с аппаратным дефектом.

Вторая проблема была решена: хост исключён из обслуживания. После этого misaligned-stack краши исчезли. OpenAI также улучшила fatal signal handler для выявления подобных проблем из логов без core dump'ов и изменила control plane для переиспользования VM вместо переустановки, чтобы упростить детекцию неисправных хостов.

Первая проблема, return-to-null краши, оказалась 18-летней race condition в GNU libunwind. После исключения данных от неправильного хоста оставшиеся крахи стали гораздо проще для анализа и отладки.

Ключевые факты

OpenAI обнаружила две независимые проблемы в своей системе Rockset через анализ 12+ месяцев production core dump'ов: аппаратный дефект на одном физическом хосте и 18-летний race condition в libunwind
Эпидемиологический подход (анализ всей популяции случаев) раскрыл закономерности, скрытые при врачебном подходе (исследование одного случая): географическое распределение, сроки начала, совпадения с hardware SKU
Rockset, облачная система для поиска и real-time аналитики, критична для ChatGPT: индексирует knowledge base пользователя и даёт LLM доступ к релевантным данным при ответе
C++ даёт производительность, но отсутствие гарантий памяти означает, что баги приводят к segfault'ам; OpenAI использует folly's fatal signal handler для логирования и core dump'ов на Azure blob storage
Методика: build a high-quality data set о ВСЕЙ популяции проблемы, затем ищи паттерны (сроки, регионы, hardware), разделяй на кластеры, вместо углубления в один противоречивый случай

Почему это важно

Надёжность инфраструктуры critical для LLM-систем: каждый segfault нарушает качество и reliability целого сервиса. OpenAI обслуживает миллионы запросов; невоспроизводимые краши уходили недели на отладку. История показывает, как потеря контроля над данными (смешивание двух багов в один 'синдром') блокирует отладку. Эпидемиологический сдвиг был именно о том, чтобы восстановить контроль через данные.

Кому это важно

Инженеры инфраструктуры и системщики, работающие с C++ в high-scale окружениях (облако, data centers). Разработчики, отлаживающие невоспроизводимые проблемы. Авторы и мейнтейнеры GNU libunwind и других low-level библиотек (их баги могут оставаться скрытыми годами).

Как это применить

При анализе массовых, невоспроизводимых проблем: собери данные со ВСЕЙ популяции случаев (логи, core dump'ы, метрики), найди корреляции (время, регион, hardware, версия), разбей на кластеры по паттернам, а не пытайся объяснить все случаи одной гипотезой. Используй автоматизацию и скрипты для класс-ификации, чтобы избежать bias'а. Ищи моменты, когда контрпримеры от разных проблем мешают друг другу.

Можно ли доверять

OpenAI опубликовала детальный техотчёт с full context (компиляция, ABI, сигналы, stress tests, kernel source), core dump'ы проанализированы автоматически и вручную. Misaligned-stack проблема решена через физическое исключение хоста и улучшение детекции. Return-to-null обозначена как 18-летний race condition в libunwind, заслуживает проверки в самой libunwind, но логика OpenAI убедительна (две популяции крахей, разные паттерны).

Риски и подводные камни

Аппаратные дефекты облачных VM могут быть скрыты месяцами до детекции (хост оставался в обслуживании до анализа). 2. Race conditions в open source библиотеках могут тихо жить в дополнении, если conditions rare. 3. Смешивание data от разных проблем в логах и мониторинге легко приводит к неправильным гипотезам, требуется дисциплина в классификации.