Мой личный топ, его можно смело пристраивать ниже поста:
- Use after free.
- Lock free algo dead lock.
- Virtualized third-party app behavior differ from the non-virtualized one
- irql_not_less_or_equal
Нуну. Удачи в нахождении и исправлении race в ядре ОС по невнятным юзеровским жалобам - удача тебе ой как понадобится. Всё остальное выше написанное - детский лепет в сравнении с гонками.
Для остальных. Race condition - состояние гонки. Состояние при котором результат выполнения криво написанного кода сильно зависит от того какой поток успеет быстрее что-то выполнить чем другой (возможно что-то другое). Что приводит к трудно выводимым багам, поскольку обычно всё работает, но иногда в силу того что планировщик задач раздал кванты времени как-то иначе, успевает то, что обычно не успевало и дальше мы ловим сегфолты, дедлоки, нулпоинтеры или неожиданные ошибки данных (возвращаются старые или даже испорченные данные).
Проблема в том, что в оригинальном сообщении автора выше нет ни слова про ядро, это раз. Никто не спорит что отладка в ядре накладывает серьезные ограничения и усложняет любую проблему.
Там, где в силу требований к производительности, нет нужды использовать опасные сложные lock/wait-free схемы, достаточно пользоваться написанными за тебя примитивами, критическими секциями и условными переменными и так далее. Отловить баги в таком радикально проще чем в lock/wait free схемах. Которые являются частным случаем ваших race conditions только намного более плохим, потому что они полагаются на то что автор учел все особенности работы компилятора, спекулятивного выполнения команд и алгоритмов когерентности l1 кэша используемой архитектуры/архитектур верно. Учитывая то, что проблемы в таком коде если он был первоначально отлажен проявляются очень редко и несистемно, а любой дебаг принт, сколь угодно быстрый на таких скоростях радикально меняет поведение кода и ошибка с вероятностью перестанет воспроизводиться... из методов отладки остается лишь медитация над кодом, эксперименты, гадания с целью локализовать дефектную часть и отчаянье. Это два.
Если знать про что есть последняя проблема из моего списка - там есть явное указание на то что это ядро. Это вызов функции, обработчика или ещё чего-то на уровне прерывания на котором оно не должно было быть вызвано. Как правило может вызваться почти чем угодно. От примитивной ошибки, где ты действительно вызвал функцию там где не следовало, до коррапта чужой памяти, который вызвал такой эффект неделю спустя или редкий дефект железа, который привел к последовательности действий которая обычно никогда не происходит и всё в таком духе. Метод отладки - от часов до недель которые придется искать зацепки в крэшдампе. Это три.
Наконец. Откуда такая непонятная заносчивость, и автоматическая постановка себя папой над другими? Непонятно.
два года, имхо, еще норм
все равно за 2 года (а может и раньше) проект зачастую надоедает, "приедается" и начинается болото и рутина
а вот если 2 месяца - вот это попоболь заметней
только нормально вкатились, команда притерлась с большего, процесс наладили - и хуй тебе, Марио, твоя принцесса в другом замке, начинай заново
У меня была ошибка, которая воспроизводилась только тогда, когда билд осуществлялся в составе Yocto Image на билд-сервере. И билд этот занимал несколько часов.
Моя любимая ошибка - ощибка в драйвере NDIS минипорта, откорпоративного файирвола, которая не давала законнектиться к интернету беспроводному WiMax модему. Воспроизводилась только с модемом конкретного поставщика. В Токио. В Японии.
- Use after free.
- Lock free algo dead lock.
- Virtualized third-party app behavior differ from the non-virtualized one
- irql_not_less_or_equal
RACE CONDITION
Проблема в том, что в оригинальном сообщении автора выше нет ни слова про ядро, это раз. Никто не спорит что отладка в ядре накладывает серьезные ограничения и усложняет любую проблему.
Там, где в силу требований к производительности, нет нужды использовать опасные сложные lock/wait-free схемы, достаточно пользоваться написанными за тебя примитивами, критическими секциями и условными переменными и так далее. Отловить баги в таком радикально проще чем в lock/wait free схемах. Которые являются частным случаем ваших race conditions только намного более плохим, потому что они полагаются на то что автор учел все особенности работы компилятора, спекулятивного выполнения команд и алгоритмов когерентности l1 кэша используемой архитектуры/архитектур верно. Учитывая то, что проблемы в таком коде если он был первоначально отлажен проявляются очень редко и несистемно, а любой дебаг принт, сколь угодно быстрый на таких скоростях радикально меняет поведение кода и ошибка с вероятностью перестанет воспроизводиться... из методов отладки остается лишь медитация над кодом, эксперименты, гадания с целью локализовать дефектную часть и отчаянье. Это два.
Если знать про что есть последняя проблема из моего списка - там есть явное указание на то что это ядро. Это вызов функции, обработчика или ещё чего-то на уровне прерывания на котором оно не должно было быть вызвано. Как правило может вызваться почти чем угодно. От примитивной ошибки, где ты действительно вызвал функцию там где не следовало, до коррапта чужой памяти, который вызвал такой эффект неделю спустя или редкий дефект железа, который привел к последовательности действий которая обычно никогда не происходит и всё в таком духе. Метод отладки - от часов до недель которые придется искать зацепки в крэшдампе. Это три.
Наконец. Откуда такая непонятная заносчивость, и автоматическая постановка себя папой над другими? Непонятно.
P.S. Жду долбоеба, который скажет, что это не аниме
Через два работы разработчиков проект закрыли, всех уволили.
все равно за 2 года (а может и раньше) проект зачастую надоедает, "приедается" и начинается болото и рутина
а вот если 2 месяца - вот это попоболь заметней
только нормально вкатились, команда притерлась с большего, процесс наладили - и хуй тебе, Марио, твоя принцесса в другом замке, начинай заново