Привет
!
Читая о концепции программирования по контракту, наткнулся на довольно глупенькое упражнение с очевидным "мотыльком, застрявшим между контактами". Как оказалось погодя, у этого перепончатокрылого было даже имя особое — Heisenbug. Копнул немного глубже и (п)оказалось интересно...
Гейзенбаги (Хайзенбаги) — особая разновидность багов, исчезающих или мутирующих по мере анализа причины возникновения.
Типичный пример такого зверька: баг проявляющийся в релиз-версии программы, но сидящий партизаном в отладочной. Своим именем баг обязан принципу неопределённости Гейзенберга (Heisenberg uncertainty principle). Этот термин из квантовой физики заключается в следующем факте: наблюдение влияет на измерение наблюдаемых объектов. На самом деле, это не совсем точная трактовка принципа, но именно в этом варианте его чаще всего (ошибочно) используют.
Одной из типичных причин возникновения гейзенбагоподобного поведения является часто практикуемая очистка памяти перед началом выполнения программы в отладочном режиме. Другая причина — возможность наблюдения за переменными из отладчика, например, за аксессорами свойств класса. Это, в свою очередь, влечет выполнение кода, способного изменить и состояние программы. Еще одна причина — выход за границы дозволенного указателем. Большинство Гейзенбагов рождаются в местах неинициализированных переменных. Как правило, поймав жука-Гейзенбага, его довольно легко и просто нейтрализовать (тапком
).
Резюмируя:
"The more closely you look at one thing, the less closely can you see something else."
Heisenberg.
Bohr bug или Bohrbug (названы в честь боровской модели атома) — в отличии от Гейзенбагов никуда не исчезают и не мутируют по мере анализа причины рождения. Их просто-напросто невероятно тяжело найти и пофиксить на этапе использования. Скорее даже, они никогда не будут исправлены, но если перегрузить программу или компьютер, или отменить операцию и не подходить к компьютеру до тех пор, пока не сядет батарейка в БИОСе, то жук, наверняка, уберется восвояси... до следующей нескорой вылазки. Причина же возникновения Борбага кроется скорее во входе программы в невероятно редкие состояния.
Мандельбаг (назван в честь отца фрактальной геометрии д-ра Benoît B. Mandelbrot) — баг, причины возникновения которого настолько сложны, что поведение его кажется хаотическим. Подразумевается, что счастливый наблюдатель этого животного охотнее отнесет баг к разряду Борбагов, чем к Гейзенбагскому семейству.
Впрочем, исходя из анлогии с тестом Тьюринга, существование этой категории жуков спорно: Если следователь не может отличить баг, чье поведение
похоже на хаотическое и баг, поведение которого
является хаотическим, то и различие между Мандельбагом и Гейзенбагом не существенно, т.к. невозможно сказать кто есть кто.
Иногда 'Мандельбаг' используется для описания дефекта, проявление которого не хаотическое, но причины возникновения настолько сложны, что не существует практического решения (вспомнилось: "Мы знаем, что она не имеет решения..."
). Примером может послужить баг, возникший в результате изначально неверного дизайна всей системы.
Шрединбаг предстает во всей свое красе только после того, как программа была подвержена нетрадиционному использованию, вымогательству, изнасилованию... Ой
Пожалуй, я забрал влево — нетрадиционного использования будет достаточно, для появления внеконтрактного Шрединбага. Еще один сценарий появления Шрёдинбага: программист читает исходники,
замечает в них ошибку. Теперь программа,
рабтавшая ранее как часики, ломается у всех. После того как замеченный баг чинится, программа возвращается к нормальной работе. — Не смотря на близость к оккультизму, такое бывает
. Некотрые программы таят в себе латентные Шрединбаги годами!
Имя Шрединбага унаследовано от эксперимента с
Schrödinger'ским котом. Правильно написанная программа, исполняющаяся в надежном окружении, должна работать вполне детерминировано — корректно. А раз так, то вопрос наблюдаемости (т.е. ломание программы простым чтением исходного кода), поставленный Schrödinger'ом (т.е. убийство кота открытием ящика) не может влиять на работу программы. Однако, быстрое исправление очевидно дефектного куска кода обычно куда более важно, чем попытки выяснить в силу какого таинственного стечения обстоятельств система работала сначала или почему она перестала работать. Утверждением, что система не могла работать ни при каких условиях ранее, вопреки очевидному доказательству обратного (система работала до чтения кода!), сложность вычислительных систем заставляет программиста лишь взывать к Высшим, Потаенным силам.
Например, программа баз данных могла работать сначала на малом количестве записей, включая тестовые данные, использовавшиеся во время разработки. Прошло время и программа ломается когда число записей достигает определенного порога (что абсолютно неочевидно влияет на (не)работу программы). Программист, не ведающий причины и не заметивший угрзы крэша в росте числа записей, запросто может отнести баг к категории Шрединбагов.
Еще один пример Шрединбага от Microsoft'a
тут.
Вот, собственно, и все. Отныне, во время поиска очередного мохнатого, я буду смотреть пристальнее — авось мне попадется один из "элитных"... Впрочем, кому они еще не попадались
?
PS: Во время создания "статьи" я пользовался:
Википедией,
Foldoc'ом и, конечно же
Гуглом. Надеюсь, информация искажена минимально
PPS: Спасибо, что дочитали до этого "Спасибо"
. Хочется вреить, что вам было интересно прогуляться по багопарку.
Здравствуйте, anvaka, Вы писали:
A>
Знакомый зверек... перед новым годом поймали такого... жил полтора года... и за это время на него никто не наступил не смотря на то что жил этот таракан в коде кторый выполнялся десятки миллионов раз в сутки...
Вот такие они тараканы Шреденгера.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
