В Go‑сервисе recover() может выглядеть надёжной страховкой, пока конкурентная запись в map не завершает процесс через fatal error: concurrent map writes. При этом часть гонок проходит незаметно и приводит к потере данных без единой ошибки в логах. В статье разбираемся, почему recover() не спасает в таких ситуациях, как обнаружить проблему с помощью -race и какой способ синхронизации выбрать для общей map.

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

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

Две команды git notes add добавляют заметки к двум разным коммитам одновременно. Обе завершаются с кодом 0, но одна заметка исчезает: на обычной Linux-машине — в 25 запусках из 30. Фарид Закария нашёл эту гонку своей детерминированной виртуальной машиной Rewind VM и показывает, как тремя вопросами к записанным прогонам дойти от «тест иногда падает» до одной строки в notes-utils.c, которая обновляет ссылку refs/notes/commits без проверки, что её не успел изменить соседний процесс. Патч уже отправлен в рассылку git.

Сервер отправляет по SSE три сообщения с паузой 250 мс, а клиент видит события только через 750 мс. Собрал стенд на стандартной библиотеке Python и поставил три отметки времени: байты тела ответа, текст после декодера gzip, готовое событие. Незавершённый кадр и сжатие без промежуточного сброса дают одинаковый симптом, но задержка появляется в разных точках.

Когда в моей Среде разработки К дошла очередь до отладчика, выбор был такой: по HTTP - проще, но с глюками, знакомыми по мобильной разработке; по TCP - быстрее, но протокол закрытый: им штатная среда говорит с тонким клиентом. Я выбрал TCP: снял обмен с провода и повторил его. RSA-1024 с PKCS#1 v1.5, 192 байта на тройном DES, NTLM, контрольная сумма по полям GUID и идентификатор, который нельзя делать случайным. Рассказываю, где спотыкался и что получилось: точки с условием, шаги, стек, локальные, вычисление и остановка по ошибке - на живом клиенте.