Вопрос: Какие самые печальные/курьезные по последствиям баги в вашей практике (или о которых знаете)?

Лучший ответ:
Я работаю в области программирования промышленных систем, так что баги до продакшена добираются довольно редко (хотя были и довольно забавные на грани "мистики", но они вряд ли будут интересны широкой публике - там много утомительных технических деталей).
Ну тем не менее вот вам три истории из моей практики.
История первая. Как отзывают автомобили.
Было это минус двенадцать лет тому назад.
Программировал я систему автоматического неразрушающего контроля. По конвейеру ехали свежеотлитые детали моторов, робот брал их с конвейера, рентген просвечивал и система выполняла отбраковку годен/не годен, дальше робот выкладывал их обратно на конвейер для годных или отправлял на переплавку. Скорости компьютеров были не такие как нынче, так что система состояла из пяти компьютеров, четыре из которых работали в кластере, чтобы обеспечить реальное время системе машинного зрения. На каждом крутилось специальное программное обеспечение. Парень я был молодой и горячий, интерфейсы менял как перчатки, ну и при реализации очередных требований заказчика ПО было обновлено. То, как система будет работать при наличии устаревших версий в кластере вообще не проверил за ненадобностью - ведь я съездил на завод и собственноручно выполнил полное обновление ПО на всех системах со всеми сопутствующими тестами. Инсталлятор на внутреннем сервере также был обновлен, старая версия была удалена. Однако я не знал, что несколькими неделями ранее отдел закупок решил самовольно "усовершенствовать и упростить" процесс поставки компьютеров - если раньше наш отдел сервиса получал "голый" компьютер и выполнял установку ПО на нашем предприятии, после проверок пересылая компьютер заказчику, то теперь поставщик компьютеров получил из отдела закупок образ системы, накатывал его на компьютер и отправлял его прямо на завод, минуя наш отдел сервиса. Ну вы поняли - там в образе была давно устаревшая версия ПО. В какой-то момент один из компьютеров вышел из строя - информация об этом поступила в сервис, тот переслал её отделу закупок, а он в совю очередь - поставщику компьютеров, который просто поставил новый комп на завод и заказчик собственноручно установил его в стойку (там мы реализовали "горячую замену"). Звонок главного инженера настиг меня в пятницу после рабочего дня - он сказал, что проанализировав статистические данные за последние пару недель, выяснил, что одна из систем уменьшила процент отбраковки с четырёх до трёх процентов и попросил это дело проконтролировать. Я из дома подключился к системе, скачал логи и довольно быстро выяснил, что один из компьютеров в кластере за две недели вообще не отбраковал ни одной картинки, результат его работы всегда интепретировался как "годный". Примерно двадцать тысяч деталей прошло через систему за это время. Дальше после проверки версий и совместимости стало ясно, откуда ноги растут. Я произвёл обновление ПО на дефектном компьютере. Спал в выходные очень плохо - мне снилось, как я открываю свежую газету и читаю о том, как очень известный концерн ХХХ отзывает двадцать тысяч автомобилей из-за возможных дефектов в головке блока цилиндров. В понедельник однако выяснилость, что потенциально дефектные детали ещё не отправлены на сборку и находятся на складе - часть их пустили на повторную проверку, а часть просто отправили в переплавку. История закончилась благополучно, но научила многому.
История вторая. Три робота и бутылка виски.
Было это где-то лет десять тому назад. Программировал я тогда забавный кольцевой конвейер на литейном заводе - представьте себе восьмиугольник диаметром три метра, на каждом ребре которого лежат детали. Один робот выкладывает на него детали после отпиливания приливов, затем восьмиугольник проворачивается, второй робот забирает с него детали на проверку, восьмиугольник проворачивается снова, после проверки робот выкладывает детали на него же, он проворачивается снова, затем третий робот снимает с него детали для последующей обработки или переплавки. Изюминка состояла в том, чтобы минимизировать время простоя - если робот должен был выложить деталь, ему следовало подогнать пустое ребро, а если забрать - то ребро с деталью. Все три робота работают асинхронно. Сам по себе "конвейер" представлял собой довольно хлипкую конструкцию из алюминиевых профилей. У роботов усилие - несколько сот килограммов, ну и в какой-то момент робот выложил деталь на ребро, на котором деталь уже была - и вся линия встала на сутки, ибо конвейер был полностью искорёжен. Мы съездили на завод, починили конвейер и проверили весь протокол обмена - ошибок там не было, но  мы добавили местами "двойное рукопожатие" и несколько дополнительных датчиков наличия детали. Через пару месяцев это случилось снова - на сей раз конвейер ещё не занял звою позицию, а робот выложил деталь между рёбрами и конвейер расколбасило. Снова командировка, новые датчики, новые проверки... Происходило это спонтанно, раз в квартал примерно... Сам конвейер чем-то отдалённо напоминал рулетку - повезёт/не повезёт. Ещё пару месяцев прошло, и я получаю я, значит, e-mail от главного инженера:
"...После прошлого обновления ПО поспорил я с директором на ящик пива - он сказал, что это случится снова, а я утверждал, что господин Дмитриев - ну очень способный русский программист, способный найти и устранить неисправность. И я проиграл. Теперь это случилось опять, и я проиграл коробку вина. И всё же я хочу поспорить снова - теперь на на бутылку хорошего виски, потому что всё ещё верю в вас - приезжайте и устраните или хотя бы найдите эту чёртову неисправность". 
Вообще я был более чем уверен в своём коде - там количество проверок и "рукопожатий" зашкаливало все возможные пределы, весь конвейер был обвешан датчиками как новогодняя ёлка, кроме того, при каждом происшествии код рефакторился и вылизывался снова и снова - я б такой код и на атомную станцию мог накатить. Но я также зависел от кода выкладывающего робота и был стопудово уверен, что робот порой выкладывает детальки вообще без моего разрешения. Субподрядчик же катил бочку в мою сторону, утверждая, что это я выставил соотвествующие разрешающие биты и робот отреагировал правильно. Логами припереть его к стенке ну никак не удавалось, так что сделал я следующее - поехал в соседний магазин хозтоваров, купил там бытовую систему видеонаблюдения, завёл сигналы с камер на свободные входы фреймграббера и начал писать в "чёрный ящик" не только сигналы датчиков и управляющие сигналы, но и видео того, что происходило на конвейере. Проблему нашли быстро - субподрячик напрограммировал "состояние гонки" в одном месте, и при неудачном стечении обстоятельств, от меня вобще не зависящим,  многотонный робот спонтанно выкладывал детали без спроса, чем и приводил конструкцию в негодность. Главный инженер таки выиграл своё виски, а субподрядчик оплатил всем ужин в кабаке.
История третья. "Победа".
Это было лет двадцать тому назад. Работал я тогда в компьютерном центре очень большой питерской типографии. Как-то вечером пришёл заказчик с файлом, сделанном  в пейджмекере (ежели кто помнит), и попросил вывести это дело на плёнки, причём к утру. Заказ был срочный - они решили напечатать подарочные издания ветеранам к дню Победы. Пришлось остаться в "ночную" смену. Верстальщиком была молоденькая девушка вообще без опыта работы. Шрифты она естественно принести не догадалась, вёрстка расползалась, приходилось контролировать каждую страничку и к утру я был уже практически никакой. Наконец работа была почти закончена - осталась только обложка. На обложке было одно-единственное слово: ПОБЕДА. Я отправил её на принтер, и оттуда вылезло что-то типа "ĖĀĤĈĐĶ". "Шрифт слетел" - сказал я, отправил испорченную плёнку в мусорное ведро, и вывел новую плёнку, подобрав рубленую гарнитуру, подходящую по размеру и начертанию. "А можно я это с собой заберу?" - спросила меня девушка, крутя в руках вытащенную из мусорной корзины плёнку. "Да не вопрос" - сказал я - брака не жалко. Она положила бракованную плёнку сверху пачки и упорхнула. Я получил лёгких $%&*юлей за ночную смену без уведомления начальства, и думать про это забыл.
Несколько недель спустя вызывает меня директор типографии. За столом сидят технологи, корректоры, и лежит пачка книжек. Директор взял из пачки одну из книжек, подвинул её ко мне и просто спросил "Это что?!". На красной бархатной обложке, тиснёные золотом, красовались буквы "ĖĀĤĈĐĶ". Меня начал разбирать смех. Я представил себе, как рабочий типографии отливает штамп с чудными буквами, как оператор горячего тиснения рассматривает обложку, но тем не менее продолжает выпуск... Больше половины подарочного тиража выпустили, пока не остановили. "Шрифт слетел", - только и смог выдавить я из себя, вспоминая, как юное создание вытаскивает злосчастную плёнку из мусорной корзины и кладёт сверху готовой пачки плёнок. "Что значит шрифт слетел?!" - зарычал директор. Дяденька уже в возрасте, он и представить себе не мог, как наборщик, даже в самом пьяном угаре, возьмёт шесть первых попавшихся литер из акцидентного набора семьдесят вторго кегля и вдует их на обложку. "Слушайте, а может это по-гречески или по-латыни?" - спросил технолог - "мы могли бы это дело как-то обыграть"... Короче, поскольку времени перепечатывать тираж уже не было, решили пофиксить баг, просто сделав суперобложку с "правильными" буквами. Так что если у вас дома есть красная бархатная книжка в суперобложке - разверните и посмотрите - может вашей бабушке или дедушке попался тот самый экземпляр с кракозябрами.

Худший ответ:
Не у меня, но в моей практике: htrd.su/wiki/zhurnal/2013/09/18/zabavnyj_bag
Ещё:
Останавливался шедулер ThreadX и, соответственно, продолжал выполняться только один тред, либо, когда доходило до кооперативного передачи управления. Проблема: отображённый в память регистр регистр управления таймером после записи не сразу возвращает, при чтении, новое значение. Плюс один регистр использовался для двух таймеров, соответственно, что настроить второй, нужно вычитать значение, подправить его и записать обратно, что бы параметры первого не перезаписать. Планировщик на время решедулинга гасил свой таймер, а потом активировал. Но случалось так, что после активирования не сразу обновлялся, а к этому моменту наш код успевал вычитать регистр, с погашенным значением, активировал свой таймер и записывал. В результате таймер планировщика оказывался выключенным. Гонки в прямом смысле не было: доступ планировщика из прерывания, а наш код запускается непосредственно им уже после активации. Ситуация усугублялась тем, что система могла некоторое время работать за счёт кооперативной многозадачности (например, при блокировке на мутексе, вызывается дополнительно код, проверяющий, а не готов ли какой тред, и запускает его, участие планировщика тут не нужно, аналогично при вызове других системных процедур, типа sleep(), ожидание треда и т.п.), но гасло часто в непредсказуемый момент. Это embedded ;-)