Что за шрединбаг?

Эта вики-страница рассказывает:

Schrödinbug - это ошибка, которая проявляется только после того, как кто-то читает исходный код или использует программу необычным образом, замечая, что она никогда не должна была работать в первую очередь, после чего программа сразу перестает работать для всех, пока не будет исправлена. В Jargon File добавлено: «Хотя ... это звучит невозможно, это случается; в некоторых программах скрытые шрединг-баги скрывались годами».

То, о чем говорят, очень расплывчато ..

Может ли кто-нибудь привести пример того, как выглядит шрединбаг (например, в вымышленной / реальной ситуации)?

По моему опыту картина такова:

• Система работает, часто годами
• Об ошибке сообщается
• Разработчик исследует ошибку и находит немного кода, который кажется совершенно ошибочным, и заявляет, что он "никогда не работал"
• Ошибка исправляется, и растет легенда о коде, который никогда не работал (но работал годами)

Давайте будем логичны здесь. Код, который никогда бы не сработал ... никогда бы не сработал . Если он сделал работу , то утверждение ложно.

Итак, я собираюсь сказать, что ошибка, точно описанная (то есть наблюдение некорректного кода, перестает его работать), явно бессмысленна.

В действительности то, что произошло, - это одна из двух вещей:

1) Разработчик не полностью понял код . В этом случае код обычно является беспорядком, и где-то в нем есть большая, но неочевидная чувствительность к некоторому внешнему условию (скажем, конкретная версия ОС или конфигурация, которая определяет, как какая-то функция работает незначительным, но значимым образом). Это внешнее условие изменяется (скажем, при обновлении или изменении сервера, которое считается несвязанным), и при этом код нарушается.

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

В этой ситуации нужно понимать, что идея о том, что «это никогда не могло бы сработать», доказуемо ложна (потому что она сработала).

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

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

Разработчик смотрит на это и заявляет, что «это никогда не могло бы сработать», но пользователи говорят: «ерунда, мы использовали это годами», и они в некотором роде правы, но считают, что это неуместно (и обычно не упоминают до разработчик находит точное условие , при котором указывают они идут «о да, мы делаем , что в настоящее время и не делали раньше») изменилось.

Здесь разработчик прав - он никогда не мог работать и никогда не работал.

Но в любом случае одна из двух вещей верна:

• Утверждение «это никогда не сработало» верно и никогда не сработало - люди просто думали, что это сработало
• Это сработало, и утверждение «это никогда не могло бы сработать» является ложным и объясняется (как правило, разумным) отсутствием понимания кода и его зависимостей.

Поскольку все упоминают код, который никогда не должен был работать, я приведу вам пример, с которым я столкнулся около 8 лет назад в умирающем проекте VB3, который был преобразован в .net. К сожалению, проект нужно было обновлять до тех пор, пока не будет завершена версия .net, и я был единственным, кто даже отдаленно понимал VB3.

Была одна очень важная функция, которую вызывали сотни раз для каждого расчета - она ​​рассчитывала ежемесячные проценты по долгосрочным пенсионным планам. Я воспроизведу интересные части.

Function CalculateMonthlyInterest([...], IsYearlyInterestMode As Boolean, [...]) As Double
    [about 30 lines of code]
    If IsYearlyInterestMode Then
        [about 30 lines of code]
        If Not IsYearlyInterestMode Then
            [about 30 lines of code (*)]
        End If
    End If
End Function

Часть, отмеченная звездочкой, имела самый важный код; это была единственная часть, которая сделала фактический расчет. Очевидно, это никогда не должно было работать, верно?

Потребовалось много отладки, но в конце концов я нашел причину: IsYearlyInterestModeбыло True, и Not IsYearlyInterestModeбыло также верно. Это потому, что где-то вдоль строки кто-то приводил его к целому числу, затем в функции, которая должна установить его в истинное значение, увеличивал его (если он Falseравен 0, для него было бы установлено значение 1, то есть VB True, поэтому я могу видеть логику там), затем бросьте его обратно в логическое значение. И я остался с состоянием, которое никогда не может случиться, и все же случается все время.

Не знаю реального примера, но чтобы упростить его с примером ситуации:

• Какое-то время ошибка не замечается, потому что приложение не запускает код в условиях, приводящих к его сбою.
• Кто-то замечает это, делая что-то за пределами обычного использования (или проверяя источник).
• Теперь, когда ошибка замечена, приложение не будет работать до нормальных условий, пока ошибка не будет исправлена.

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

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

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

Копаясь в реализации, я нахожу некоторые основные логические ошибки, Frobnicate()которые делают его всегда неудачным. В управлении исходным кодом я вижу, что функция не была изменена с момента ее написания, что означает, что функция никогда не работала так, как задумывалось. Почему никто этого не заметил? Я просматриваю остальную часть набора источника и обнаруживаю, что все существующие вызывающие объекты Frobnicate()игнорируют возвращаемое значение (и, следовательно, содержат свои собственные незначительные ошибки). Если я изменю эти функции, чтобы проверить возвращаемое значение, как они должны, то они тоже начнут давать сбой.

Это частый случай условия № 2, о котором упоминал Джон Хопкинс в своем ответе, и он удручающе распространен в больших внутренних библиотеках.

Вот настоящий Schrödinbug, который я видел в каком-то системном коде. Корневой демон должен общаться с модулем ядра. Таким образом, код ядра создает несколько файловых дескрипторов:

int pipeFDs[1];

затем устанавливает связь по каналу, который будет подключен к именованному каналу:

int pipeResult = pipe(pipeFDs);

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

Затем однажды мне пришлось перенести код на новую архитектуру. Он перестал работать, и ошибка, которая никогда не должна была работать, была обнаружена.

Следствием Schrödinbug является Heisenbug, который описывает ошибку, которая исчезает (или иногда появляется) при попытке исследовать и / или исправить ее.

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

На самом деле, это, как правило, вызвано тем или иным из следующего:

• влияние этой оптимизации, когда код, скомпилированный с -DDEBUG, оптимизирован до уровня, отличного от сборки выпуска
• незначительные временные различия из-за реальных коммуникационных шин или прерываний, которые слегка отличаются от симулированных "идеальных" фиктивных нагрузок

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

Я видел несколько Schödinbugs и всегда по той же причине:

Политика компании требовала, чтобы каждый должен был использовать программу.
Никто действительно не использовал это (главным образом потому, что не было никакого обучения для этого.)
Но они не могли сказать руководству об этом. Таким образом, все должны были сказать: «Я использую эту программу в течение 2 лет и никогда не сталкивался с этой ошибкой до сегодняшнего дня».
Программа действительно никогда не работала, за исключением меньшинства пользователей (включая разработчиков, которые ее написали).

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

У меня есть пример из моей собственной истории, это было около 25 лет назад. Я был ребенком, занимался программированием элементарной графики в Turbo Pascal. В TP была библиотека под названием BGI, которая включала в себя некоторые функции, которые позволяют копировать область экрана в блок памяти на основе указателя, а затем копировать его в другое место. В сочетании с блистанием на черно-белом экране его можно использовать для простой анимации.

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

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

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

Он никогда не должен был работать, он никогда не должен был работать (и на любой реальной ОС он не работал бы), но он все же работал, и как только он сломался - он остался сломанным.

Это происходит все время, когда люди используют отладчики.

Среда отладки отличается от реальной - без отладчика - производственной среды.

Работа с отладчиком может маскировать такие вещи, как переполнение стека, потому что кадры стека отладчика маскируют ошибку.

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

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