Отладка *

На первый баг ушло десять часов и пять гипотез, ни одна не подтвердилась. На второй — ещё десять часов и семь попыток. А потом каждый закрылся за минуты: в одном случае хватило строчки в дампе состояния, в другом — первого запуска с самодельным обработчиком падений.

Три истории о гонках в M:N-рантайме языка Nova: что сломалось, как я это искал и что в итоге нашло баг. Объясняю простыми словами, знать устройство рантайма не нужно, а в конце — чек-лист для отладки гонок в многопоточном коде.

Ещё пять – семь лет назад зона ответственности сантехника в основном ограничивалась трубами, запорной арматурой, коллекторами и подключением оборудования. Но само сантехническое оборудование изменилось. Сегодня сантехника становится частью цифровой инфраструктуры жилья. К экосистемам умного дома подключаются системы контроля расхода и качества воды, водонагреватели, насосное оборудование, системы защиты от протечек с датчиками и кранами с электроприводом, и другие инженерные устройства. Их работу можно контролировать через приложения и голосовых помощников, объединять с другими устройствами и включать в общие сценарии автоматизации дома.

Вместе с оборудованием изменился и набор задач на объекте – настройка Wi-Fi, приложений и сценариев автоматизации, что ещё недавно было задачей отдельных специалистов по умному дому и совсем другой, более высокооплачиваемой нишей.

Сегодня эта граница стирается и показательный тому пример на рынке – умная система защиты от протечек воды. Инженерное устройство с полной интеграцией в экосистему умного дома – это наглядный кейс, на котором хорошо видно, какие именно новые компетенции открываются перед специалистом, и почему за эти компетенции рынок готов платить больше.

Знакомая ситуация: в системном промпте четко написано, что модель делать не должна ни в коем случае, а она все равно это делает. Вы переписываете правило, добавляете «ВАЖНО», капслок и примеры, становится чуть лучше, а потом снова за старое. В какой‑то момент начинаешь подозревать модель, ее настройки (например, температуру) или провайдера.

Мы наступили на это в голосовом ассистенте и разобрали случай до конца: переиграли боевые запросы и меняли по одному фактору за раз. Промпт оказался ни при чем. Модель слушалась собственной истории диалога, и ниже я покажу, как мы это нашли, какие получились цифры и что с этим делать, если вы строите на LLM чат‑бота, агента или ассистента.

Может ли робот понять, что пульт оператора выключен? Казалось бы, простая задача. Но опущенный рычажок и разряженный или выключенный пульт для оператора разные ситуации, и во второй роботу стоило бы подсказать об этом вслух.

Мы думали, что разница обязана быть видна в данных: приёмник публикует положение рычажков каждые 23 миллисекунды. Оказалось, при потере связи он продолжает публиковать как ни в чём не бывало, те же кадры и тот же интервал, только со значениями безопасного состояния, которые не отличить от настоящих. Мы проверили шесть гипотез: failsafe-значения, события переходов, таймауты, траекторию рычажка, логи закрытого модуля, параллельное чтение порта. Все шесть провалились.

Рассказываем, как методично прийти в тупик, честно признать, что задача технически не решается, и решить её другим путём. По шагам, с выводом для всех, кто работает с закрытым сторонним железом.

Из записок доктора Матсон о расследованиях великого сыщика Войлока Сокса. Все процессы реальны. Некоторые реплики слегка драматизированы. Ни один Кодекс при подготовке рукописи не пострадал.

В Lua достаточно забыть local перед переменной, чтобы получить баг, который может долго оставаться незамеченным. По отдельности функции работают исправно, тесты проходят, а после подключения нового модуля внезапно начинают пропадать данные или меняться результаты вычислений. Разберёмся, как глобальные переменные создают такие ловушки, чем опасны манипуляции с G и ENV и как защитить код от ошибок, зависящих от порядка вызовов и загрузки модулей.

Harness — построение инфры вокруг LLM таким образом, чтобы man in the loop (человек в процессе поддержки LLM) отсутствовал.

Я решил поэкспериментировать некоторое время назад, идея была очень простой — дать агенту возможность дебажить и исследовать написанный код через логгирование до того, как он попадет в чистовик.

Дисклеймер: инструмент пилил для себя, результатом доволен (таблица с результатами в конце статьи), для локальных моделей буст получил, для агентов клода тоже, если есть идеи как дотюнить — добро пожаловать в комментарии.

Реальный продакшен-инцидент: пул соединений забит, активных запросов дюжина, рестарт помогает. Claude нашёл причину за двадцать минут. Нормальный человек на этом обновил бы библиотеку и пошёл дальше, но у меня две RTX 5090 стояли без дела, и зудел вопрос: а локальная 27B-модель смогла бы? Тот же промпт, тот же код, та же песочница, семь локальных моделей, около 40 прогонов. В промпте, кстати, осталась одна правдоподобная, но ложная гипотеза инженера. Я не планировал делать из неё ловушку. Она стала главным фильтром всего эксперимента.

Всем привет! Меня зовут Игорь Белов, я инженер в команде Мобильной Архитектуры Авито. Больше 6 лет занимаюсь iOS-разработкой, а ещё мне нравится изучать фундаментальные темы Computer Science и разбираться, как те или иные вещи работают под капотом.

В статье я расскажу, как исследовать произвольные приложения macOS с помощью отладчика LLDB и сопутствующих инструментов, и тем самым прокачать свой повседневный инструментарий разработчика. Сначала исследуем произвольно запущенные процессы в macOS с помощью LLDB. Затем на основе собранных знаний сделаем инъекцию своего кода, чтобы изменить их поведение. Ещё немного затронем теорию, подготовим и настроим окружение. В конце я посоветую, что почитать, чтобы углубиться в тему.

Статья будет полезна инженерам любого уровня, которым интересно узнать, как устроены привычные вещи. И да, это образовательная статья, а примеры из неё не предназначены для обхода защиты и несанкционированного вмешательства в чужие сервисы или данные.

На создание этого материала меня вдохновило выступление Дерека Селандера — ему уже около десяти лет, но оно всё ещё актуально. Мне захотелось взять идею оттуда в более прикладном виде и спроецировать на современную повседневную разработку.

При работе с STM32 приходится решать несколько повторяющихся задач: настроить сборку, подключить библиотеки, записать прошивку и проверить её поведение на плате. После изменений эти действия нужно выполнить снова — желательно тем же способом и с понятным результатом.

В моих проектах для этого постепенно сложился набор инструментов и примеров. Одни помогают описывать сборку, другие — прошивать микроконтроллер, третьи — сохранять действия в отладчике в виде повторяемых тестов. Отдельная часть посвящена инструкциям для ИИ-ассистентов, участвующих в разработке.

Хочу показать, как эти проекты связаны и где могут пригодиться.

Наивность, fail-fast, fallback, failback, оптимизация и стратегия — на слизне, на кухне и на JavaScript

Эти слова программисты произносят каждый день, и почти каждый понимает их немного по-своему. Можно было бы начать со словаря: шесть терминов, шесть определений. Это был бы наивный план — в том самом смысле, о котором пойдёт речь ниже, — и к концу статьи станет видно, почему я от него отказался.

Вместо словаря будет задача. Понятия появляются по одному — тогда, когда без них уже нельзя двигаться дальше. Каждое получает образ, точное определение и код.

В прошлой статье я сделал обзор популярных способов отладки embedded: GDB-клиент -> GDB-сервер (OpenOCD) -> программатор -> целевой МК. Тогда я сформулировал свои субъективные требования к “идеальному” программатору. И на тот момент у меня уже был минимально рабочий вариант такого программатора. И вот спешу представить к чему привели меня изыскания в этом направлении.

Мы переводили карту парковок с растровой подложки на векторные тайлы и получили чёрный экран. Без единой ошибки в консоли: ни исключения, ни предупреждения, идеально чистый лог. Единственной уликой оказалось отсутствие запросов за тайлами — воркер MapLibre не попал в сборку, потому что Rollup не умеет разбирать шаблонную строку в new URL(…, import.meta.url). Разбираем этот баг и ещё два из той же серии: как смена города убивала Leaflet и почему событие load у карты не наступает никогда.

Спросил у Claude Code «Ответь одним словом: работает». Двадцать девять символов. На сервер ушло 305 042 байта — 113 460 токенов, ответ из четырёх.

Поставил между агентом и сервером прокси на сорок строк Python и разобрал тело запроса по частям. Системный промпт — четыре процента. Восемьдесят пять процентов — описания 137 инструментов, из которых 107 принёс один MCP-сервер, которым я в этой сессии не пользовался. Ещё 29 тысяч символов добавил хук плагина. И на каждый ход уходит второй запрос, о котором я не просил.

То же самое проделал с Codex CLI: 29 килобайт, 9 817 токенов, а системный промпт при этом такой же длины. Дальше — таблица, что убирается флагами (один MCP-сервер стоил 52 тысячи токенов на запрос), что это значит для окна и кэша, и скрипт, чтобы посмотреть свой первый запрос.

За полгода Tailscale 19 раз столкнулась с повреждением баз SQLite, но воспроизвести сбой не удавалось: между инцидентами проходили то часы, то недели. Инженеры собирали диагностику прямо в продакшене, проверяли одну гипотезу за другой и в итоге нашли редкую гонку между записью и созданием контрольной точки — баг, который скрывался в SQLite минимум 16 лет.

Полгода назад я начал писать сжатую файловую систему для macOS. Идея была довольно простой. В macOS уже существует decmpfs — встроенный механизм прозрачного сжатия файлов. Приложение продолжает видеть обычный файл, хотя физически его содержимое может храниться в сжатом виде. Но у этого подхода есть неприятное для моей задачи свойство: после изменения файла сжатие может исчезнуть.

Например, можно сжать node_modules, получить приличную экономию места, потом запустить сборку — часть файлов перезапишется, распакуется, и каталог постепенно снова начнёт занимать почти исходный объём. Мне хотелось другого поведения: если файл лежит на сжатом диске, он должен оставаться сжатым независимо от того, сколько раз его переписывали.

Если у вас когда-нибудь ломалась SD-карта, то вы знаете, как обычно решают эту проблему: снова попробовать вставить её в фотоаппарат, сменить кард-ридер, проверить на другом компьютере и, если вообще никто её не обнаруживает, признать карту мёртвой.

Но почему она умерла?

Это уже гораздо более интересный вопрос, потому что смерть SD-карты необязательно означает смерть памяти NAND, и совершенно не подразумевает потерю хранящихся на карте данных.

Монолитные SD-карты особенно любопытны тем, что бóльшая часть их электроники заключена в один сплошной корпус. Нельзя просто взглянуть на плату и сразу же распознать контроллер, чипы NAND, конденсаторы, резисторы и другие элементы, из которых состоит традиционное флэш-устройство.

Недавно нам встретился прекрасный пример этого. Переданная клиентом SD-карта SanDisk Ultra 32GB ничем не распознавалась. Изначально казалось, что потребуется сложное восстановление флэш-памяти, но в результате всё свелось к двум микроскопическим компонентам, спрятанным внутри карты. Я решил, что это будет подходящей возможностью продемонстрировать процесс восстановления.

После прошлого поста я вдохновился на продолжение, помимо того, что я изначально хотел его доработать, я также увидел, что количество людей увидевших мой пост перевалило за 7,5 тысяч.

Поэтому я сел за доработку согласно предыдущему плану, что я писал в той статье. Я решил идти по первому пути и сделать логирование асинхронным. Дело в том, что так это становится изолированной переменной, ведь банально легче доработать и тестировать, чем заниматься рефакторингом всего кода и разносить его по разным процессам. После доработки я конечно же решил протестировать новую версию и я очень удивился результатам. Изначально throughput действительно вырос, что обрадовало меня.

Я уже думал писать статью, но решил мимолетом запустить 175 воркеров. Это решение создало неожиданную проблему - задача оказалась обработана за 11 секунд до ее создания.

Привет, Хабр! Пилю потихоньку пет‑проект и решил поделиться тем, что вылезло при первом же деплое.

Откуда взялась эта штука 

Основная занятость у меня связана с ИИ, но есть ещё подработки по 1С — в основном администрирование: обновления, настройка оборудования, выгрузки и прочее. Всё взаимодействие идёт в Telegram: множество чатов, в каждом свои задачи, у каждой свой дедлайн и своё техническое окно, когда её вообще можно делать. Базу не обновишь в разгар рабочего дня — значит, задача не просто «к пятнице», а «в пятницу после семи».

Пока задач несколько, они держатся в голове. Дальше начинается путаница: помнишь, что на этой неделе у кого‑то обновление, а у кого именно — уже нет. Я начал забывать про клиентов. Писал на бумажке. Бумажка не работает по простой причине: про неё тоже надо вспомнить. Она лежит рядом и молчит. А напоминание должно приходить само и туда, где я и так сижу целый день. Так и родилась мысль сделать свой блэкджек.

Мой сервис обрабатывает большой поток PDF от самых разных генераторов. В начале июня один‑единственный файл уложил его на 30 минут: HPA раздул поды до потолка, и все они наглухо повисли, 100% CPU, обработка стоит, очередь копится, алерты сыпятся пачками. Расследование в трёх актах: ложный подозреваемый, закомментированный panic и санитайзер, не знавший алфавит до конца.