Отладка *

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

На прошлой неделе моё внимание привлёк этот коммит:

858d2e434dd 8372584: [Linux]: Замена чтения proc для получения CPUtime потока на clock_gettime

diffstat выглядел интересно: +96 вставок, -54 удалений. В changeset был добавлен бенчмарк JMH из 55 строк, что означало реальное уменьшение кода продакшена.

Прямо сейчас в вашем ядре есть баги, которые не найдут ещё многие годы. Я знаю это, потому что проанализировал 125183 бага с отслеживаемой меткой Fixes: за 20-летнюю историю Git ядра Linux.

Прежде чем баг обнаружат, он в среднем живёт в ядре 2,1 года. Но в некоторых подсистемах ситуация гораздо хуже: для драйверов шины CAN этот срок в среднем составляет 4,2 года, для сетевого протокола SCTP — 4,0 года. Самый долгоживущий баг в моём датасете (переполнение буфера в ethtool) прятался в ядре 20,7 года. Баг, который я проанализирую в статье подробно (утечка refcount в netfilter), прожил 19 лет.

Я создал инструмент, перехватывающий 92% исторических багов в тестовом датасете на этапе коммитов. Ниже я расскажу, какую информацию мне это дало.

В этой статье я хотел поделиться опытом тестирования своего контроллера динамической памяти на ПЛИС.

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

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

В этом тексте я бы хотел провести курс молодого бойца по использованию CLI в микроконтроллере. Расскажу про API той CLI, которая получилась у меня.

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

Порой бывает так, что вы скачиваете open-source репозиторий, а там нет файлов .project и .сproject для eclipse или файлы .project и .сproject есть, но они по каким-то причинам повреждены и IDE их не может открыть.

Тем не менее прошивка собирается командой make all. Ты ее прошиваешь и LED не мигает. Очевидно, что прошивка зависла. Где-то свалилась в HardFault_Handler.

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

Оптимизация и профилирование C++: branchless-код проиграл обычному if-else. Что пошло не так? Разбираемся вместе.

Хотите увидеть нечто любопытное? Вот, как устранили проблему «антеннагейта» на iPhone в 2010 году. 20 байт.

iOS 4.0: 8d ff ff ff 91 ff ff ff 95 ff ff ff 99 ff ff ff 9d ff ff ff iOS 4.0.1: 86 ff ff ff 98 ff ff ff 9e ff ff ff a7 ff ff ff b0 ff ff ff

Контекст: в 2010 году, когда выпустили iPhone 4, пользователи заметили, что если взять телефон определённым образом, то количество полосок сигнала сети падает с 5 до примерно 2. Спустя насколько недель компания опубликовала письмо, в котором свалила вину за это на неправильную формулу.

Публикуем новый полный перевод хрестоматийной статьи Эдсгера Дейкстры. Этот текст, опубликованный в 1968 году в журнале Communications of the ACM в формате письма в редакцию, заложил основы структурного программирования, впервые строго аргументировав отказ от оператора go to в пользу использования циклов и условных конструкций.

Splinter Cell (2002) была одной из первых игр, купленных мной для Xbox, и она по-прежнему остаётся одной из самых любимых моих игр. Эта игра была разработана Ubisoft на движке Unreal Engine 2, лицензированном у небольшой инди-студии Epic Games, которая и сегодня продолжает использовать и лицензировать этот движок в современных малобюджетных инди-играх наподобие Fortnite и Halo: Campaign Evolved.

Я начал заниматься программированием/хакингом благодаря видеоиграм, и до сих пор получаю удовольствие от дата-майнинга/исследования контента, вырезанного из тех немногих игр, в которые играю сегодня. Недавно я решил поискать онлайн вырезанный контент Splinter Cell, и был удивлён отсутствием раскопанной информации. За исключением прототипа игры для Xbox, в котором содержались два уровня, вырезанные из розничной версии для Xbox и некоторые другие мелкие отличия, информации об игре практически нет.

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

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

Команда Spring АйО подготовила перевод разбора реального бага в HotSpot от разработчика OpenJDK. Во время работы над Project Valhalla его Java-объекты и классы начали «исчезать» без участия сборщика мусора — и поиск причины привёл к одному неверному биту в заголовке объекта, miscompilation в C2 и очень нетривиальному отладочному квесту. Этот текст показывает, как устроены mark word и Compact Object Headers, чем живёт Valhalla и как системное мышление плюс флаги JVM помогают выловить самые коварные ошибки.

Каждую пару лет кто-нибудь замечает, что крупные технологические компании иногда пишут на удивление мусорный код. Если вы не работали в большой компании, то вам может быть сложно понять, почему это происходит. Уровень зарплат в крупных технологических компаниях позволяет привлекать многих компетентных разработчиков. Они работают довольно неспешно, поэтому создаётся впечатление, что у них достаточно времени, чтобы выполнять работу качественно. Как же появляется плохой код?

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

Для практики я использую локальный кластер на Minikube — он позволяет экспериментировать с компонентами Kubernetes без аренды серверов или облачных инфраструктуры.

Недавнее обсуждение опасности дверей в геймдеве напомнило мне о баге, вызванном дверью из игры, о которой вы, возможно слышали — Half Life 2. Усаживайтесь поудобнее, мы начинаем.

Когда-то я работал в Valve над проектами виртуальной реальности. Это было в 2013 году, примерно когда появился Oculus DK1. Мы с Джо Людвигом решили, что лучше всего можно понять, как будет работать VR в контексте реальной игры, портировав в неё реальную игру.

Мы выбрали Team Fortress 2 (причина этого — отдельная история, которой я не хочу здесь касаться). В TF2 использовался движок Source 1, и так получилось, что двумя другими играми Valve, тоже построенными на этом движке, были Half Life 2 и Portal 1. Поэтому побочным эффектом стало то, что они тоже будут работать в VR.

Точнее, Portal 1 «работал», однако все трюки с перспективой при прохождении через портал вызывали настоящую тошноту, поэтому играть в это было практически невозможно.

Зато HL2 игрался достаточно неплохо. Джо потратил довольно много времени на то, чтобы уровни с лодкой работали прилично.

Я расскажу о своём подходе к программированию под условным названием «хрустальный код», когда за счёт строгого следования спецификациям методов и путём минимизации проверок и валидаций мы создаём быстрое и надёжное ПО.

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

В данной статье поясню, как я разбирался в работе файловой лицензии, как новая версия программы не поддалась мне с первого раза (поэтому в этот раз патч сделан по иной схеме, но лучше с моей точки зрения), а так же поговорим о экспериментах с живым HASP ключом.

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

Привет, Хабр! Это моя первая проба пера. Статья будет на тему «как разработчик из кровавого Enterprise статейник писал». Может быть интересно либо таким же как я, либо наоборот, ребятам которые занимаются сайтами‑статейниками и подумывают в сторону работы в больших корпорациях. Словом, для всех, кто хочет посмотреть, как оно там, у других. В ходе написания статьи я буду использовать привычную терминологию и пояснять ее. Статья идет от простого к сложному, поэтому если вы из «кровавого Enterprise» — можно пролистать статью до момента деплоя (часть 2).

Команда разработчиков прислала мне на ревью свой API, в одной из частей которого множество поддерживаемых значений выражалось в виде трёх чисел:

• Минимального допустимого значения.
• Инкремента.
• Максимального допустимого значения.

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

Команда сообщила, что если инкремент равен нулю, то поддерживаются только минимальное и максимальное значения.

Я указал, что эта архитектура искушает пользователя делить на ноль.

Помню, как на собеседовании в одну крупную компанию мне задали вопрос: "Чем отличается observability от monitoring?" Я уверенно ответил что-то про "три столпа" и "unknown unknowns". Интервьюер кивнул, но потом спросил: "А зачем платить $100k в год за Datadog, если можно поставить бесплатный Prometheus?"

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

Или история о том, как в момент запуска отладки из любой среды разработки (Visual Studio 2022/2026, Visual Studio Code) я ловил ошибку: "Вызвано исключение по адресу 0x00000000 в ***.exe: 0xC0000005: нарушение прав доступа при исполнении по адресу 0x00000000"

Будем оптимизировать программы на Go. Выжимать последние наносекунды, чтобы код приближался по скорости к Си или ассемблерному. Цель - скорость, чтобы процессор был загружен на 100% при высокопроизводительные вычислениях.