Господа, меня тут озадачили лекцией в МГУ на тему багов и их последствий (на 1.5 часа). Чувствую, что моих запасов на столько не хватит   
Поэтому прошу общественность поделится интересными (и главное необычными) багами, которые встречались в вашей практике. 
В основном интересуют конечно программные баги (из мира С/С++), но и любые другие (вплоть до багов аппаратуры) подойдут.

Вот, к примеру, баг из моей коллекции -

Было это в конце 80х, когда самой крутой PC была '386я с сопроцессором'. И была написанна маленькая программа, которая что то считала и выводила несложную графику (все в DOS). У меня все работало замечательно, а вот у заказчика оно свалилось с сообщением 'Not enough memory' (что было очень странно, т.к. этой самой memory ей было нужно совсем не много). Попытка взять машину с памятью побольше успехом не увенчалась. Раскопки с TurboDebugger'ом показали удивительную вещь:
Программа использовала вычесления с плавающей точкой для расчета размеров (и площади) фигур, которые она пыталась нарисовать. По подсчитанной площади делался malloc - для выделения памяти под растр. В машине отсуствовал сопроцессор, а в программе отсуствовала проверка на его наличие   В результате все вычисления с плавающей точкой были проигнорированны, и в malloc свалился 0, что и вызвало выдачу NULL и как следствие ругань на нехватку памяти.

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

Ну если интересно в Builder по крайней мере знаю 3 бага

Интересны баги в программах (желательно своих). Или вы автор Builder'ов?

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

происходило следующее:
когда очередь io_service`а доходила до объекта этого типа, вызывался его operator(), в котором создавалась асинхронная запись использующая в качестве хендлера метод handler() этого же объекта. но проблема тут в том, что после вызова operator(), io_service удаляет из очереди этот объект, и объект разрушается. но как же быть с хендлером?  
этот код отлично работал в линуксе. но когда его собрали для вянды - начились приключения.

2. про мотиву первого.
имеется такой объект:

происходит следующее:
при разрушении объекта этого типа, вызывается cancel() у таймера.
если таймер в это время был взведен, то согласно доке, хендлер должен вызваться с error_code равном operation_canceled. но проблема в том, что вызов deadline_timer::cancel() не напрямую вызывает указанный хендлер, а при помощи io_service`а. таким образом, хендлер вызывался после того как объект уже был разрушен. плюс еще одна проблема в том, что состояние объекта-члена-данных _timer после разрушения объекта типа timer - оказывалось неопределенным. и поэтому баг воспроизводился по разному  

Это проблема учета времени жизни объектов. Ничего 'необычного' в них пока не вижу, надо что нибудь более яркое.

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

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

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

NB. Проблему неопределенного времени жизни я обязательно упомяну, так что за баги спасибо (хотя их самих я пожалуй упоминать не буду - 90% аудитории просто не поймет, в чем дело   )

  Могу поделиться такой вот классикой (Код не оригинальный )

  Такой код в принципе работает, но иногда в программе появляются чудеса. Если удалять нужно 2 подряд идущих элемента, то i++ благополучно обходит второй.

  Еще немного из классики.

1)


В общем случае не тоже самое что и 

2)


Суть в том, что первоначально код написан как 1) , затем код модифицируется до 2) . Вроде как полный эквивалент, однако ж нет. В 1м случае если <expr1> == true , то <expr2> даже не вычисляется. Во втором же случае порядок вычисления может быть произвольным. 

 Аналогично


Легким движением руки превращается в 

  Код который выглядит эквивалентным, но на самом деле 2й параметр может вычисляться раньше 1го.

По поводу первого — первый раз слышу. О_О.

  Ни разу не делал таких ошибок? Или не знал что это ошибка?   

Я как-то пробовал собрать грабли, на которые все наступали - http://forum.vingrad.ru/forum/topic-346611/view-all.html
вот история (из той же темы), с которой я сам столкнулся:

Как-то 29 марта (это существенно) подходит ко мне молодой коллега Дима и говорит, что наша программа не пишет в БД. Я, ессно, спрашиваю "что менял" - отвечает "ничего". Ставим старую версию программы - не пишет. Ставим старую версию базы - не пишет. И так продолжалось 3 дня. 1-го апреля подходит Дима и говорит, что программа стала писать в БД. Я думал первоапрельский розыгрыш. Пошёл проверил. Старая версия программы в старую версию БД пишет. Новая - тоже...
В итоге что выяснилось: эту программу писали давным-давно ещё под DOS. Дима же переделывал её под Windows. В DOS в структуре, в которой хранится дата, месяц считается от 0, а в windows'овской структуре - от единицы. При записи в базу старый формат даты преобразовывался в новый без учёта этой особенности. Таким образом получалось, что мы пытались записать в БД 29 февраля, затем 30-е, затем 31-е... СУБД отказывалась воспринимать эти даты, а вот первое марта - пожалуйста.
Как никто не заметил, что дата в БД отличается на месяц - не знаю

Alexeis, 

То есть в любом случае гарантируется порядок вычислений.

Это сообщение отредактировал(а) Qu1nt - 19.6.2012, 16:39

ага. пруф - http://liveworkspace.org/code/7a681a5dd8e3...bf434e2e6ed8ecf