Самый интересный баг, пожалуй, относится к тому времени, когда я работал над автоматизацией действий с GUI в Windows.
Если мне память не изменяет, программа внедрялась в приложение-"жертву", подгружая в него свою DLL и подменяя обработчик оконных сообщений. В программе были некие действия, которые должны были выполняться когда пользователь с приложением ничего не делает, то есть, не жмет на кнопки, не двигает мышью и т.д.
Выглядело это так: в очередь отправлялось наше оконное сообщение. Когда подходил его черед, обработчик смотрел, есть ли еще сообщения для интерфейсного потока, и если нет, то выполнял требуемые действия. Если есть, просто отправлял сообщение обратно в конец очереди, и процедура повторялась.
Это работало везде, кроме Гугл Хрома, и мне выпало разбираться, почему. Загрузив Хромиум и собрав его в дебаг-конфигурации, я погрузился в отладку.
В итоге выяснилось, что в Хроме реализован точно такой же механизм idle listener. Они тоже постили в очередь сообщение и смотрели, не претендует ли кто-то еще на обработку. Даже если пользователь ничего не делал, в списке всегда было наше сообщение, и Хром уступал ему. Обработчик нашего сообщения, в свою очередь, находил сообщение Хрома, и так они бесконечно расшаркивались перед дверью не в силах в нее войти.
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
про свои баги я умолчу... все это НИЧТО по сравнению с этим: 500-mile email
не знаю как у тебя с английским, русский пересказ если и есть то гугл поможет тебе найти %)
ничего более "зачетного" мне в реальной жизни не попадалось (ну или я не помню уже)
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
Был у меня баг, в системе предоплаченых звонков. Тестировал — путем звонка с системы(клиентом был мой ноут) — на свой мобильный. Ошибся в одной цифре — набирал не свой мобильный. Хотя ответ был, мой мобильник не звонил(естественно) — я ругался довольно 3-х этажным матом(до отбоя), и так раза 3. Потом когда понял, пот прошиб — где-то есть чувак с похожим на мой мобильный номером, ему приходит вызов с каллерид скажем "№№888№№№", где на него начинают орать матом. Долго смеялся, потом перезвонил — извенился, на той стороне от шока наверное ничего не поняли, чувак говорил — что ничего плохого не делал(видно подумал что я из кровавого КГБ).
А вот самый запоминающий ся баг, Эт в институте было — подошел я, значит, к аппарату кофе попить и мелочь ему всю спихнуть — сунул пять копеек и по кнопке случайно ударил и он бац — кофе самого дорого налил (за любую монетку оказываться наливал)!!! Ух и попил я тогда кофе и какао — халявое такое вкусное было.
Re[2]: Самый интересный баг, с которым вы возились
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
История 1
Работали мы как-то над VoIP приложением использующим довольно специфическое оборудование.
Настолько специфическое что за приемлемые деньги удалось использовать процессор 750MHz когда все вокруг уже пользовались намного более мощными процессорами.
Функциональность была реализована, клиенты уже начали покупать наше изделие, и только тогда дали добро на оптимизацию производительности.
Надо сказать что при пиковой нагрузке проц загружался на 90-95%.
Руководитель проекта доказывал менеджерам что задача имеет высокую вычислительную сложность и надо раскошелится на процессора подороже.
Прошло не меньше недели в поисках бага.
Каких только теорий не было: и зависимость от времени суток, и баги в блокировки ресурсов...
Решение оказалось на удивление простыхм: обертка над http://linux.die.net/man/2/nanosleepиногда формировала параметр неправильно — количество наносекунд превышало 10^9.
Соответственно системный вызов возвращал код ошибки, но обертка его игнорировала и запускала ожидание еще раз. Упорно повторяла вызов пока аргумент не получался правильным.
Баг поправили за пару минут и пиковая нагрузка на проц упала до 30-35%.
История 2.
Работам над тем же приложением.
Один из клиентов начинает жаловаться что приложение падает. Просим прислать нам пошаговое описание как убить систему. У других клиентов и у разработчиков все работает нормально.
Присылает: включить сервер, заходит пользователь, все падает.
Опять неделю ищем проблему, находим несколько критических багов из-за которых все должно падать, устанавливаем клиенту обновления один за одним. Все равно все падает.
Наконец терпение менеджеров исчерпывается и к клиенту выезжает специалист.
На месте была обнаружена ошибка сборки сервера: все вентиляторы всасывают воздух внутрь корпуса (и соответственно ни один из них не выкачивает воздух наружу).
В середине корпуса образовалась зона без вентиляции и температура вышла далеко за гарантийные пределы.
После переустановки вентилятора наше приложение стало нормально работать.
История 3.
VoIP приложение, интенсивно пользуем Asterisk.
Внезапно он начинает падать, причем core dump сообщает что невозможно преобразовать строку "0\0" в число.
Ясно что врет, но что именно происходит непонятно.
В конце концов выясняем что Астериск не может прочитать данные с диска, а поскольку разработчики в такое не верили, то errno проверяется уже в другом месте.
Дополнительное расследование показало что обслуживающий персонал уронил сервер. Физически. С высоты примерно 1.5м на бетон.
После замены битых дисков в массиве приложение снова работает.
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
Не совсем баг.
После написания одной проги я обнаружил, что она слишком медленно работает. Я вставил функции определения времени и начал рефакторинг. Изменил программу — так же медленно. Еще изменил — то же. Хорошенько пораскинул мозгами, провел существенную оптимизацию, которая, по идее, должна была сократить время на порядок — прога по-прежнему работала как черепаха. Оказалось, время уходило на вызов процедур, возвращающих время, одна из которых была во внутреннем цикле.
Программировать сложно. Но не программировать еще сложнее.
Re[4]: Самый интересный баг, с которым вы возились
D>Ковыряние в багах не имеет никакого отношения к решению задач. Прямо наоборот: оно отнимает время от этих самых задач и, соответственно, лишает удовлетворения от создания нового функционала.
Умение быстро понять причину сложного бага — это показатель аналитических способностей и квалификации. Отладка интересного бага, завершившаяся победой, дает азарт и удовлетворение почище чем кодинг.
Re[2]: Самый интересный баг, с которым вы возились
Здравствуйте, LaptevVV, Вы писали:
LVV>Про венгерскую запись, про все эти хендлы и т.п. — типа минимальный ликбез.
я надеюсь не ваших рук дело с BAD_POOL_HEADER
и ещё раз для вновь поступающих к чтиву рсдн непримену упомянуть — С++ -- оцтой
Опишу три случая, которые запомнились на всю жизнь и с которыми пришлось достаточно долго провозиться.
Случай 1. Писал я как-то программу под ДОС на встроенном компьютере с 486 процессором – он использовался в одном устройстве и достаточно активно работал с различного рода «железом». Одной из задач у него была ретрансляция команд по RS232 с между двух портов (с одного устройства на другое), при этом некоторые из команд обрабатывались самим компьютером, да и он мог генерить «высоко приоритетные команды». В общем были там очереди с приоритетами на портах, а сами обработчики прерываний RS были написаны на ассемблере (остальная программа была на Borland C++ 3.1). Работал я в паре с другим разработчиком, который проектировал и программировал все остальной «железо». Итак, вечер перед отправкой «изделия» заказчику – у нас все отлажено и более-менее работает, а мы возимся с какой-то мелочевкой, в общем «допалировываем». И вдруг после исправления чего-то в коде Си перестает работать передача команд... Полностью. При этом исправленный кусок к передачи данных ни каким образом не относился. Просматриваю файлы – все нормально – никаких «подозрительных» мест не видно. Восстановление изменененого кода к прежнему состоянию — ничего не дает – передача команд не работает. Восстановление предыдущего ПО для «железа» (оно правилось параллельно) — так же не помогает. А со старой версией программы – все работает. В общем провозились мы с этой проблемой где-то час – два, пока я не сравнил построчно все файлы проекта, и не обнаружил, что в какой-то момент в обработчике прерывания RS исчезла одна строчка с ассемлерной командой – видимо при переключении окон в борланде я ее случайно удалил какой-то комбинацией клавиш... С одной стороны сейчас это звучит смешно – найти такую проблему пара минут, но тогда пришлось серьезно понервничать и выучить, что изменения могут быть не только в том коде, корый правишь, а и в любом другом месте проекта, даже который и «не трогал».
Случай 2. Случился с одним моим коллегой, но я принимал горячее участие в поиске «бага». Писал он программу для микроконтроллера на Си. И все было нормально, но вдруг одна функция перестала модифицировать одну переменную. Все остальное она делала как нужно, а вот одну переменную наотрез отказывалась модифицировать. Как мы это раскапывали – это отдельная история (отладчиком воспользоваться было нельзя и приходилось выводить промежуточные значения на спец. индикатор, ну и «дергать» ноги микроконтроллера для просмотра на осцилографе), но в результате выяснилось следующее: внутри одной функции, достаточно сложной, одна глобальная переменная должна была инкрементироваться, а она оставалась неизменной. При этом постепенно стала проявляться интересная картина – эта переменная внутри функции все-таки изменялась, но при выходе из функции она вдруг принимала исходное значение. Чего только не было испробовано и каких только предположений не было высказано – вплоть до ошибок в компиляторе. Но все оказалось намного банальнее – указанная глобальная переменная передавалась внутрь функции в качестве параметра (т.к. программист начитался умных книг и знал, что «использованиеглобальных переменных – зло» ), а внутри функции этот параметр был объявлен точно таким же именем, как и глобальная переменная... Из-за этого при беглом просмотре кода создавалось впечатление, что меняется глобальная переменная. Тем более, что она изменялась в конце достаочно длинной функции и именно туда было сосредоточено все внимание.
Случай 3. Самый «крышесносный» и интересный в моей жизни. Устанавливали мы как-то наше «изделие» у заказчика на заводе и адаптировали наш софт для интеграции его с роботами заказчика. Адаптация шла в основном в программе микроконтроллера нашего изделия. И вот в какой-то момент, добавив простейшее действие, что-то типа a += b + 100; мы обнаружили, что наше «изделие» перестало адекватно реагировать на команды робота. При этом частично реагировало нормально, а частично «сошло с ума» — мы даже описать это не смогли бы, настолько реакция оказалась «чудной». Убрали строчку – все нормально. Добавили – фигня. Изменили строчку c =b + 100; a += c; — ерунда, но по другому. Разнесли строчки – одну чуть выше по коду, другую чуть ниже – с роботом все восстановилось. Пожали плечами и вздохнули с облегчением – сдадим сегодня «изделие» заказчику. Вдруг обнаружили – «отвалилось» запоминание параметров во флэш-памяти. В общем не буду утомлять, но бились мы с этим несколько часов, пока не нашли какую-то комбинацию, когда все заработало (на самом деле там пришлось добавлять не одну строчку и подобная фигня была, можно сказать, практически с каждой строчкой). Но «изделие» сдали (и оно до сих пор там работает), а сами с недоумением поехали домой. Дома же, когда начали разбираться, то обнаружили следующее – после «заливки» программы в микроконтроллер в ней «портился» один байт. Изначально наш код по объему был чуть менее 64k, а во время доработок у заказчика перевалил через эту границу. Загрузчик же программы (утилита третьей фирмы) имел баг и в микроконтроллер на записывал последний байт в 64k блоке, вернее обнулял его.
Были еще случаи и с переполнением секундных счетчиков в 16 бит, и, как результат, снятия сигнала готовности на одну секунду раз в 18 минут (65536 / 3600). И поиск ошибки в программах системы, из-за чего длина участка материала, обрабатываемого нашим «изделиием» в некоторых случаях оказывалась меньше, чем заданное –причина оказалась в брызгах металла, которые постепенно нарастали в определенных местах на установке заказчика и создавали физическое препятствие . И поиск причин сбоев на конвейере, возникающих у заказчиков раз в неделю (причина оказалась в отсутствии блокировки прерываний при изменении пары переменных, которые всегда должны изменяться одновременно). Но это была «обычная» работа, которая не произвела очень сильного впечатления...
Делаем ТВ приставки.
Однажды провайдер пришел с проблемой у клиентов в домах некоторые приставки стали терять HDD.
Долго понять не могли. У провайдера в лабах не воспроизводится. У нас не воспроизводится. А в домах воспроизводится.
Грешили на перегрев HDD, мол клиенты ставят у батарей или еще где, зима же.
Тем временем число жалоб от конечных поьлзователей начало возрастать.
Провайдер начал мониторить HDD на все приставках, вести статистику. В итоге он вывел закономерность что отключались HDD у которых температура была ниже 20 градусов по Цельсию.
Мы тут дружно в голос — "ЗАМЕРЗАЮТ"
Начали копать код (код не наш, а производителя дров) выяснилось что там есть таблица температур начинающася с 20 градусов.
И кривой код который находил первое вхождение, брал индекс и вычитал 1 и брал вторую границу.
В нашем случае получался индексы 0 и -1. Ну а дальше после вычислений получалось что HDD перегрелся и система его честно выключала.
Ну и понятно почему никто не смог воспроизвести кроме клиентов, т.к. температура в лабах выше 20 градусов. Да и приставки обычно всегда работают т.е. теплые.
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
Re[2]: Самый интересный баг, с которым вы возились
Здравствуйте, ononim, Вы писали:
O>Помницца пришел нам от юзера репорт, написанный литературным языком и объемом этак на А4 страницу немелкого шрифта.. Начинался он так: "Здраствуйте уважаемые разработчики ?????, пишу я вам из библиотеки, так как после установки вашего продукта на мой компьютер ....". А что был за баг, уже не помню, он был неинтересным наверное. Да и времени дофига прошло, "продукт" тот как говорится завершил lifecycle. Зато письмо то запомнилось и фраза та до сих пор припоминается в нашем (да возможно и не только) тиме.
Напомнило
ПАСАНЫ НЕ КАЧАЙТЕ ТАМ ВИРУС КОМП СГОРЕЛ ПИШУ С ПУЛЬТА ОТ ТЕЛЕВИЗОРА
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
Хе-хе, не баг, но тем не менее... В середине лихих 90-х во времена 486-х интелей, я на 1-й своей после института работе в АСУ развлекался тем, что придумывал и встраивал в свой код, предназначенный под DOS, защиты от копирования программ. Поменял несколько работ, шло время, исходники похерены... Позвонили домой лет через 15: на богом забытой на технологическом процессе 486-й ПЭВМ, при замене её на более новую, "защита" сработала.
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
1. Скорее не баг, а случай из жизни.
Решил я как-то отрефакторить — переименовать большую кучу классов. Вбил в консоли find ... | xargs sed, собираюсь комитить и вдруг... svn говорит что ничего не изменилось. Просматриваю файлы в IDE — файлы изменились. Просматриваю cat'ом — изменились. Пытаюсь комитить, делаю diff — файлы, как-будто старые. В итоге оказалось, что я случайно вместе с исходниками поменял файлы в служебных подпапках .svn.
2. Интересный баг был в кодогенераторе gcc-llvm 4.2 для iOS, заключался в неправильном высчитывании указателя в выражениях типа Base * base = someDerived; если указатели для базового класса и наследника отличались, т. е. в случае виртуального наследования. Проявлялось как вызов не той виртуальной функции (и последующий креш, конечно). Решилось откатом к gcc 4.2, clang-llvm тогда не способен был нормально прожевать boost.
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
1. std::string Name = Node.getName();
На таком банальном коде приложение валилось с ошибкой, как это ни странно.
С getName было все в полном порядке, падение было именно в std::string, причем падало
только внутри одной функции, при специфических условиях. После долгого "разматывания"
исходников, включая многочисленные сторонние библиотеки, а также опций сборки, оказалось,
что некто пошаманил с препроцессором и опциями выравнивания данных, еще до подключения
проектом общих глобальных заголовков. Как писал потом автор "идеи", это было сделано в
целях что-то там оптимизировать в плане сериализации данных, передающихся по сети.
2. Настраивал удаленный доступ к компьютеру.
Там было что-то вроде TeamViewer-а, только с очень упрощенной функциональностью.
Настроил все, надо бы проверить. Запускаю виртуальную машину, включаю в ней интернет,
через RDP подключаюсь к специально выделенному для тестов компьютеру. На этом компьютере
запускаю программу-клиент для удаленного доступа и вбиваю в нее IP своего компа...
И здесь вдруг появляется забавный эффект — подключившись, я вижу свой десктоп с окном
запущенного RDP-сеанса, а в нем — десктоп тестового компа, на котором снова отображается
окно RDP-сеанса, только поменьше, а в нем опять десктоп тестового компа, еще меньше, и т.д.
И так они завораживающе открываются друг в друге, открываются медленно, одно за другим,
уходя все дальше вглубь, в бесконечность, а у моей Windows тут начинается жуткий своппинг,
тормоза, шуршание жесткого диска... Но я не мог остановиться и сидел зачарованный, пока
все окончательно не заглючило и систему пришлось перезагружать.
3. Баг примечателен в первую очередь своей психологической подоплекой.
Он появлялся фантомно, исключительно в релизных сборках и исключительно во время всяких важных
презентаций у начальства. Его выслеживали "с фонарями" в течение нескольких месяцев, с помощью
логов, крэш-дампов, отчетов, спец. билдов и прочих техник. Но самое прикольное, что почему-то
за многие месяцы никто не занялся этим багом вплотную, надеясь, что "партизанская" война и
выслеживание вот-вот дадут свои плоды. То есть, вместо того, чтобы сесть и починить, все
негласно ждали, пока какой-нибудь очередной крэш-дамп не зафиксирует точно проблемное место и
все будет кончено. Так длилось месяцами. В конце концов баг "обнаглел" и стал ронять систему
все чаще и чаще, как бы заявляя о себе, пока однажды один из сотрудников не "разозлился" на
него и со злости нашел и пофиксил его минут за 15 (там просто отсутствовала проверка на NULL).
Re[4]: Самый интересный баг, с которым вы возились
Pzz>>Сказка, конечно. Скорость распостранения сигнала в проводах заметно меньше скорости света. DM>в проводах как-раз таки и нет задержки. это не оптика.
Re[6]: Самый интересный баг, с которым вы возились
DM>что вас удивляет? что в проводе скорость распространения сигнала равна С?
Всегда равняется или для разных материалов изоляции все-таки она разная? Для всех частот скорость распространения волнового пакета одинакова или все-таки нет? Радиоволна будет двигаться с одинаковой скоростью в вакууме и в меди, или все-таки нет? Чем отличается скорость фазовая от скорости групповой и какая их них имеется в виду, когда мы говорим о передаче сигнала? А почему? Как связана скорость передачи сигнала со скоростью движения электронов? А фотонов? Что такое С и каков физический смысл этой величины? А можно ли двигаться быстрее С?
Рассуждайте лучше про веру и бога, а не о физике, там неудобных вопросов некому задавать.
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
Давным-давно было. Проект в VC6. Падало рандомно где угодно.
Бился долго. Думаю, что это все-таки какая-то хитрая бага в компиляторе.
Там был класс, в котором была переменная-член, являющаяся экземпляром класса-обертки для ADO-рекордсета. Т.е. этот класс наследовался от автоматически сгенеренного студией класса-обертки над COM-интерфейсом рекордсета. За ним шел обычный числовой мембер. Т.е. что-то вроде этого:
class COLOLO : public что-то
{
...
CADORecordset m_oRecordset;
int m_nAnyNumber;
}
и вот при записи в m_nAnyNumber переписывался, похоже, указатель на интерфейс в m_oRecordset.
Решилось все установкой выравнивания структур в 4 байта для всего проекта.
Короче, при выравнивании в 8 байт адреса m_nAnyNumber и this в m_oRecordset совпадали
пытался впомнить -- завис. Кто умеет могзовых багов отлаживать?
Если серьезно, то запомнился баг с shell скриптом: я полагался на тот факт, что после сортировки каких-либо строк, (какой бы ни была локаль) строки с одинаковым префиксом будут идти вместе.
Оказалось, что в не C locale эта "гарантия" может вероломно нарушаться.
А так как на этой сортировке была построена логика -- фактически я таким образом на шелле оперировал с деревьями, а строки были путями в дереве, то это аукалось нетривиальным образом черех километр от этого бага.
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
как-то когда тестировала приложение в томкате с 200 одновременными пользователями — обнаружила что система начинает намертво зависать в какой-то момент
оказался классический дедлок в томкате связанный с фиксированным количеством возможных тредов
Первым вспомнился смешной баг, хотя смех пришел уже вслед за желанием оторвать кому-то все конечности и отправить исходники на codewtf.
Работал я на поддержке проекта с ядром на C++, который занимался выгрузкой и загрузкой данных в БД. Проект по большей части был написан американской командой (исходники этого периода не блещут высоким стилем, но понятны и работают), потом года на три отдан вьетнамцам. Вьетнамцы что-то пытались писать, но ожиданий не оправдали, и код передали нам.
Тестер пожаловалась, что в DB2 не загружаются данные в поля типа дата/время. Может быть, это был и не DB2 вовсе, детали уже позабылись, но сути это не меняет.
Судя по логам, в параметрах INSERT-выражений, передаваемых как строки, день был перепутан с месяцем. Задача выглядела простой. Найдя примерно следующий код
Здравствуйте, Grue, Вы писали:
G>В итоге выяснилось, что в Хроме реализован точно такой же механизм idle listener. Они тоже постили в очередь сообщение и смотрели, не претендует ли кто-то еще на обработку. Даже если пользователь ничего не делал, в списке всегда было наше сообщение, и Хром уступал ему. Обработчик нашего сообщения, в свою очередь, находил сообщение Хрома, и так они бесконечно расшаркивались перед дверью не в силах в нее войти.
И как исправили?
Re[3]: Самый интересный баг, с которым вы возились
Помницца пришел нам от юзера репорт, написанный литературным языком и объемом этак на А4 страницу немелкого шрифта.. Начинался он так: "Здраствуйте уважаемые разработчики ?????, пишу я вам из библиотеки, так как после установки вашего продукта на мой компьютер ....". А что был за баг, уже не помню, он был неинтересным наверное. Да и времени дофига прошло, "продукт" тот как говорится завершил lifecycle. Зато письмо то запомнилось и фраза та до сих пор припоминается в нашем (да возможно и не только) тиме.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
Может не самый интересный, но текст под рукой. Писали на PC XT, понадобились чтение с диска и запись на диск.
Так как код идентичный за исключением самого вызова, я решил экономить на размере:
EXT_PROC@ _doserror, __CDECL__
OPEN_CODE@ _DOS
PUB_PROC@ abswrite, __CDECL__
mov [byte ptr cs:exec+1], 26h ; int 26h
PUB_PROC@ absread, __CDECL__
arg drive:byte, nsects:word, lsect:word, buffer:far_ptr
push bp
mov bp, sp
push si
push di
push ds
mov al, [drive]
mov cx, [nsects]
mov dx, [lsect]
lds bx, [buffer.ptr]
exec:
int 25h
pop cx
pop ds
jc fail
xor ax, ax
exit:
pop di
pop si
pop bp
ret
fail:
xor ah, ah
add ax, 13h
call _doserror@
jmp exit
END_PROC@ absread, __CDECL__
END_PROC@ abswrite, __CDECL__
CLOSE_CODE@ _DOS
end
Все работало пока не пришли PC AT. Запись перестала работать.
Лазар
Re[2]: Самый интересный баг, с которым вы возились
Не то чтобы интересный баг, но довольно трудный для обнаружения причин, причем у меня случался регулярно, но я каждый раз забывал о том что такое бывает.
Запущенная программа в режиме отладки в Visual Studio внезапно прекращает свою работу, без выдачи каких-либо сообщений дебаггером.
Как правило, свидетельствует о какой-то банальной ошибке (типа ссылки на null), которая происходит в отдельном потоке. Почему-то дебаггер не всегда обнаруживает такие ошибки, приходится искать их по всему коду методом пристального взгляда, или же расставлять логи в каждом методе.
Здравствуйте, 3V, Вы писали:
3V>Давным-давно было. Проект в VC6. Падало рандомно где угодно. 3V>при записи в m_nAnyNumber переписывался, похоже, указатель на интерфейс в m_oRecordset.
Тоже был аналогичный случай. И тоже запомнился.
Прога на С.
Переменная реального типа int во внешнем модуле была заявлена как long. Из-за чего внешний модуль портил соседнюю память.
Тогда я познакомился с возможностью внутрисхемного отладчика ставить брэйк-поинт на изменение ячейки памяти.
Re[2]: Самый интересный баг, с которым вы возились
Здравствуйте, abibok, Вы писали: A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
не про баг ,а про один из моментов осознания собственной глупости:
подрабатывал в одной инвестиц конторке, надо было выводить данные из metastock pro
в quik, по метастоку документации не нашёл, поэтому много времени проводил в softice,
а в тот день надо было идти на экзамен к 15, ориентировался на часы в компе,
вышел с запасом, а в универ пришёл, как оказалось, в 16-45, осознание пришло в пустой аудитории
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
1. Ну, может и не самый интересный. но запомнился своей моралью, так сказать.
Году в 84-85 сидели мы с моим другом в подвалах НПО Аврора.
Писали ось на бортовую ЭВМ. На ассемблере типа PDP-11
И вот написал я подпрограмму в 22 команды длиной.
Запускаю — не работает!
Ищу ошибку — ну не вижу, блин!
Ошибаться ж негде — всего 22 команды!
Минут 5-7 пялился в код, потом говорю: Лев, что за дела ? 22 команды не работют!
Тот не поворачивая даже головы: Ищи ДВЕ ошибки.
Я — почему две?
Он — по статистике 1/10 часть кода ошибочна...
Вдохновленный таким напутствием сел я и карандашиком на бумаге расписал выполнение всех 22 команд за несколько шагов цикла.
И нашел ДВЕ ошибки!
Запомнилось...
2. Опять же запомнилось
Писал я первую свою книжку Экспресс-курс С++.
В 2003 году.
И в одной из последних глав решил написать о программировании на WinAPI (глава получилась номер 13, что как бы намекает... )
Про венгерскую запись, про все эти хендлы и т.п. — типа минимальный ликбез.
Ну, поскольку до того я на WinAPI реально не писал, решил сделать простое приложение — оконную таблицу умножения...
Написал, все окошки соединил, все сообщения передаются, все работает — ура!
И решил, естественно, поиграться: с размерами, цветами, шрифтами...
Цитата из книжки:
Например, в процессе отладки рассмотренного приложения, я довольно часто экспериментировал с организацией дочерних окон и их цветами.
И в один момент я забыл поставить скобки (выделены полужирным) в операторе установки цвета фона в функции регистрации класса окна:
wc.hbrBackground = (HBRUSH)(COLOR_BTNFACE + 1);
В результате фон окна оказался совсем не таким, на который я рассчитывал. Я "убил" на поиск ошибки около часа, пока не сообразил, в чем дело. Таких примеров можно привести много.
Недаром Чарльз Петцольд в своей книге "Программирование для Windows 95" назвал первую программу "HelloWin",
тонко намекая на праздник "нечистой силы".
...
Тоже запмнилось.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Самый интересный баг, с которым вы возились
Здравствуйте, artem.komisarenko, Вы писали:
AK>Здравствуйте, abibok, Вы писали:
A>>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
AK>1. Скорее не баг, а случай из жизни. AK>Решил я как-то отрефакторить — переименовать большую кучу классов. Вбил в консоли find ... | xargs sed, собираюсь комитить и вдруг... svn говорит что ничего не изменилось. Просматриваю файлы в IDE — файлы изменились. Просматриваю cat'ом — изменились. Пытаюсь комитить, делаю diff — файлы, как-будто старые. В итоге оказалось, что я случайно вместе с исходниками поменял файлы в служебных подпапках .svn.
до боли знакомая картина
после того как я сам себе устроил такую подлянку, я себе сделал макросы под bash для поиска и замены и повесил их на Fn в консоле
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
Эх, столько их было но все забылось...
А так на днях — в продакшн один сервис не стартовал. В конфиге (key=value), в строке где password к одному сервису, после собственно пароля, затесался один space. Trim, как выяснилось, никто не делал. Много нервных клеток ушло, пока разобрались
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
ну вот вчера к примеру. ставлю винды8 на ssd с винта, на котором естественно есть загрузочная запись. как создать загрузочную запись на ssd nt60 /force? пробовал без сторониих утилит даже под админом? так чтобы можно было грузится чисто с ssd не подключая винт?
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
Однажды заказчик прибежал к нам тыча пальцем в ТЗ. Там было черным по белому написано, что записи вида Х удаляться не должны. Мы только развели руками, единственное обращение к таблице сводилось к select * from X; и засовыванием результата в грид. Высказали предположение, что сотрудники лезут в базу руками и правят ее. Поскольку базы раздавались по всему краю, обеспечить их безопасность мы не могли и посоветовали административные меры. На что заказчик отвечал, что у пользователей просто ума не хватит. Вобщем записи время от времени исчезали, заказчик ругался, мы разводили руками — select удалять записи не умеет. Компонент, который делал аудит всех исполняемых программой конструкций DML, удаление не фиксировал. Разгадка оказалась проста, однажды за пивом мы допытали одного из пользователей, как он это делает. Тот долго ломался, но потом хитро улыбнулся, зашел в программу, выделил строчку в гриде и нажал Ctrl+Del. Строчка исчезла. Запись в базе тоже. Оказывается, чересчур умный DbGrid умел распознавать строки вида select from table, и конструировал остальное. Наш аудит просто не ловил эти команды, они шли в обход компонента который умел их перехватывать.
Re[3]: Самый интересный баг, с которым вы возились
Здравствуйте, Mihas, Вы писали:
M>Переменная реального типа int во внешнем модуле была заявлена как long. Из-за чего внешний модуль портил соседнюю память. M>Тогда я познакомился с возможностью внутрисхемного отладчика ставить брэйк-поинт на изменение ячейки памяти.
Лучше бы вы познакомились с идеей включать (от слова #include) те хидеры, где внешние символы задекларированны в те сишники, где они фактически определены. Тогда ошибку поймал бы компилятор.
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
Баг? Из последнего — WEB-RTC интеграция своего источника трафика в WEB-RTC...
Изучив исходники, море TODO, качество и доля реализации RFC, качество кода, архитектуру, реализацию алгоритмической логики, прожоливость — прихожу к выводу, что WEB-RTC — это самый большой баг от Google, что я встречал в жизни...
Re[2]: Самый интересный баг, с которым вы возились
Еще был замечательный "баг" от Microsoft до сих пор работает. Выдает при установке драйвера пользователю какой-то дурацский диалог — а хотите ли поставить не подписанный драйвер... а подпись только в MS делается, да и еще за деньги... Исправили перехватом функций из Kernel в памяти, вставив jmp на успешную проверку перед вызовом диалога... Теперь устанавливается не подписанный без глупых вопросов...
2. Баг jvm в лохматые годы, происходящий строго в определенном месте выполнения(результат расследования)
3. Баг(или фича) компилятора Скалы, который давал NPE там, где его ну вообще никак быть не должно. Краткая суть после расследования:
жаба-код
class SomeClass {
def do(value: Int) {printf(value)}
}
Да, value — null, но какая проблема передать его в метод? Результатом бы должен быть вывод "null" в sysout, а летить NPE.
Догадался декомпилировать джавовский код. Компилятор перед вызовом делает value.intValue(), и потом оборачивает его в скаловский Int. Проверки на null нету, потому и NPE. Вроде все понятно стало, но поначалу было ооочень непонятно.
4. Баг(точнее, кривая документация) одного девайса, вотчдога. Он умеет следить сразу за 16 устройствами, для каждого свой таймаут "отзыва", после которого идет разрыв цепи питания. Нам нужно было следить всего за одним, но при этом команда конфигурации девайса принимала сразу все 16 параметров, и никак иначе. Ну, без задней мысли отправил девайсу эту команду с первым параметром реальным, и нулями в остальных 15 значениях. Думаю, уже понятно, что дальше было — девайс намертво завис, а служба поддержки порекомендовала мне больше так не делать, а девайс выкинуть в мусорку. Через некоторое время запрет на нули появился в официальном мане по командам...
5. Сильно вумный пинпад. Писал работу с пинпадом, немецкого производства. Там надо, в частности, задавать различные ключи по довольно мудреному протоколу, причем само значение вводить только аппаратно с клавиш пинпада, т.е. софт вообще к ключам не имеет доступа ни на чтение, ни на запись. Ключ — 32 байта в 16-ричном виде(при ввода с клавы всякие там Enter, Cancel и пр. спецкнопки соответствуют буквенным цифрам из HEX). Естественно, вводил для теста мастер-ключа одинаковые цифры, чтобы не забыть, ибо если забыть мастер-ключ, то пинпад можно выкидывать(или везти в сертифицированный сервис в Германии для разблокировки). Хрен там — ошибка, и все. После долгой переписки с местным сервисом, и их переписки с производителем, выяснилось, что команды я шлю абсолютно верные, но пинпаду не нравится простота мастер-ключа: ему подавай что-то посложнее! Сгенерил рандомку, записал ее, ввел — все заработало...
Что-то еще было, может, напишу.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[2]: Самый интересный баг, с которым вы возились
Здравствуйте, 0x8000FFFF, Вы писали:
FFF>Еще был замечательный "баг" от Microsoft до сих пор работает. Выдает при установке драйвера пользователю какой-то дурацский диалог — а хотите ли поставить не подписанный драйвер... а подпись только в MS делается, да и еще за деньги... Исправили перехватом функций из Kernel в памяти, вставив jmp на успешную проверку перед вызовом диалога... Теперь устанавливается не подписанный без глупых вопросов...
Ты шутишь ?
Re[2]: Самый интересный баг, с которым вы возились
Здравствуйте, 0x8000FFFF, Вы писали:
FFF>Еще был замечательный "баг" от Microsoft до сих пор работает. Выдает при установке драйвера пользователю какой-то дурацский диалог — а хотите ли поставить не подписанный драйвер... а подпись только в MS делается, да и еще за деньги... Исправили перехватом функций из Kernel в памяти, вставив jmp на успешную проверку перед вызовом диалога... Теперь устанавливается не подписанный без глупых вопросов...
Сурово. И как оно, работает в виндах с последними апдейтами? Антивири не верещат на такую крамоль?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[3]: Самый интересный баг, с которым вы возились
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, 0x8000FFFF, Вы писали:
FFF>>Еще был замечательный "баг" от Microsoft до сих пор работает. Выдает при установке драйвера пользователю какой-то дурацский диалог — а хотите ли поставить не подписанный драйвер... а подпись только в MS делается, да и еще за деньги... Исправили перехватом функций из Kernel в памяти, вставив jmp на успешную проверку перед вызовом диалога... Теперь устанавливается не подписанный без глупых вопросов...
E__>Сурово. И как оно, работает в виндах с последними апдейтами? Антивири не верещат на такую крамоль?
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Здравствуйте, 0x8000FFFF, Вы писали:
FFF>>Еще был замечательный "баг" от Microsoft до сих пор работает. Выдает при установке драйвера пользователю какой-то дурацский диалог — а хотите ли поставить не подписанный драйвер... а подпись только в MS делается, да и еще за деньги... Исправили перехватом функций из Kernel в памяти, вставив jmp на успешную проверку перед вызовом диалога... Теперь устанавливается не подписанный без глупых вопросов...
KA>Ты шутишь ?
Нет х) Уже 10 лет как работает подмена в памяти процесса исполняемого кода kernel32.dll x) Кто же защитит — все же в usermode...
Re[2]: Самый интересный баг, с которым вы возились
Это говорит о том, что решаемые по работе задачи — тоска и рутина. В интересных проектах и баги интересные.
А еще это хороший вопрос на интервью, хорошо помогает выйти на разговор с кандидатом.
Re[3]: Самый интересный баг, с которым вы возились
Здравствуйте, abibok, Вы писали:
D>>Нету в багах ничего интересного.
A>Это говорит о том, что решаемые по работе задачи — тоска и рутина. В интересных проектах и баги интересные. A>А еще это хороший вопрос на интервью, хорошо помогает выйти на разговор с кандидатом.
Ковыряние в багах не имеет никакого отношения к решению задач. Прямо наоборот: оно отнимает время от этих самых задач и, соответственно, лишает удовлетворения от создания нового функционала.
Re[2]: Самый интересный баг, с которым вы возились
Здравствуйте, LaptevVV, Вы писали:
LVV>Вдохновленный таким напутствием сел я и карандашиком на бумаге расписал выполнение всех 22 команд за несколько шагов цикла.
Непонятно, звчем тебе напутствие понадобилось. На ЕС ЭВМ это был самый действенный метод отладки. Одно условие — нельзя было ничего пропускать, типа "а тут все понятно".
Re[3]: Самый интересный баг, с которым вы возились
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, LaptevVV, Вы писали:
LVV>>Вдохновленный таким напутствием сел я и карандашиком на бумаге расписал выполнение всех 22 команд за несколько шагов цикла.
P>Непонятно, звчем тебе напутствие понадобилось. На ЕС ЭВМ это был самый действенный метод отладки. Одно условие — нельзя было ничего пропускать, типа "а тут все понятно".
На ЕС ЭВМ, помнится, все гонялись за книгой о дампах памяти...
Которые позиционировались как средство отладки...
Хотя на ЕС писали практически только на Фортране и PL-1...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Самый интересный баг, с которым вы возились
Здравствуйте, LaptevVV, Вы писали:
LVV>На ЕС ЭВМ, помнится, все гонялись за книгой о дампах памяти... LVV>Которые позиционировались как средство отладки...
Об этом только слышал от старших. Но говорили, что дампы — это крайнее средство для особо тяжелых случаев. Машинного времени, опять же, вечно не хватало.
LVV>Хотя на ЕС писали практически только на Фортране и PL-1...
На Коболе и на Ассемблере. О софте на Коболе я упоминал как-то. Видел пару лет назад. Дата выпуска — 1974 год.
Пока писал, вспомнил историю, может, даже по теме.
Замена ЭВМ на компьютеры у нас шла медленно и с опозданием. Поэтому о ЕС ЭВМ, о перфокартах, о дележе машинного времени я не только слышал.
Пришла к нам на ВЦ очередная версия одной софтины. Добавили к ней разработчики одну операцию, о времени выполнения которой ничего нигде не было сказано. Выделили на нее на всякий случай полтора часа. Запустили, стали ждать.
Через полтора часа приходят забирать машину. А она работает, лампочками подмигивает.
Позвали системщиков. Говорят, зациклилась. Те посмотрели, говорят, нет, машина работает штатно.
В общем, продлилось это все около трех часов. задача успешно завершилась.
Через несколько месяцев получили мы обновление этой софтины. Выделили нам время на долгоиграющую операцию. Запустили, собрались пойти перекусить. Вдруг девочки-операторы из смены прибегают, говорят, что задача закончилась. Думали, упала. Посмотрели протоколы — все нормально. Работала программа вместо трех часов что-то около минуты.
Несколько позже мы нашли библиотеку исходников. Оказалось, что написана эта программа была на Ассемблере.
Было это вообще давно ... тогда ещё 286 нормальной машиной была. Своей же машины у меня не было, программировал я дома на бумажке, а машинное время было на спецкурсах в школе два раза в неделю. Код на Turbo Pascal 7.0 с ассемблерными вставками, DOS. Что-то простое, не более 1000 строк.
Ввело меня в полный ступор следующее поведение участка кода — при пошаговом исполнении и моём контроле всех переменных в дебаггере, код исполнялся абсолютно верно, ровно так как и предполагалось, но стоило запустить программу на исполнение без дебаггера, результат был другим. Программа не падала, не ломалась, просто выдавала другой результат.
Это был шок ... Современная физика скажет что так и должно быть — результат зависит от факта наблюдения
В силу неопытности, и недостатка машинного времени, я потратил на исследование этой проблемы около месяца. И понял что к чему только когда попытался переписать весь проблемный участок кода на ассемблере и представить себя на месте среды Turbo Pascal. Тогда я понял что регистр DS один, и дебаггер по-любому где-то его для себя кэширует. Моя же программа его нагло изменяла и потом забывала вернуть назад. Собственно это и была ошибка. По DS адресовались переменные Pascal.
А под дебаггером всё работало, так как он использовал правильное значение DS.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, LaptevVV, Вы писали:
LVV>>На ЕС ЭВМ, помнится, все гонялись за книгой о дампах памяти... LVV>>Которые позиционировались как средство отладки...
P>Об этом только слышал от старших. Но говорили, что дампы — это крайнее средство для особо тяжелых случаев. Машинного времени, опять же, вечно не хватало.
Ну, мы гонялись, хотя писали на ПЛ... LVV>>Хотя на ЕС писали практически только на Фортране и PL-1...
P>На Коболе и на Ассемблере. О софте на Коболе я упоминал как-то. Видел пару лет назад. Дата выпуска — 1974 год.
С Коболом я столкнулся на минске-32. На кабельном заводе в отделе АСУ писали весь софт на нем....
Русский был Кобол
Программа выглядела почти как просто текст: Сложить, вычислить, вызвать...
[...] P>Несколько позже мы нашли библиотеку исходников. Оказалось, что написана эта программа была на Ассемблере.
Я на ЕС ассемблер использовал только в одном случае.
Тогда существовало неграсное соревнование между программерами СССР — кто напишет самую короткую программу чтения информации
из поля Parm в операторе JCL exec
Самая короткая была в составе СУБД ИНЕС (разработчик тот самый Михаил Донской).
Мне удалось сократить на 1 команду — 42 команды.
Гордился страшно...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Самый интересный баг, с которым вы возились
Здравствуйте, Лазар Бешкенадзе, Вы писали:
ЛБ>Может не самый интересный, но текст под рукой. Писали на PC XT, понадобились чтение с диска и запись на диск.
Писал на контроллере обмен с диском. Подпрограмма записи/чтения сектора. В ПЗУ работала без проблем. В ОЗУ не успевала после определения готовности выбора сектора читать/писать. Баг выловил быстро, но удивление не проходило. Там тупо стоял цикл на саму себя на команде готовности, а команда чтения была следующей за определением готовности.
Re[6]: Самый интересный баг, с которым вы возились
Здравствуйте, LaptevVV, Вы писали:
LVV>Русский был Кобол LVV>Программа выглядела почти как просто текст: Сложить, вычислить, вызвать...
Я видел русский Кобол. ЕМНИП, там с падежами проблемы. Несколько неудобно читать. А "нормальный" Кобол я видел сравнительно недавно. Мне структуры присылали для разбора. DATA DIVISION, верно? Документации с середины 70-х так никто и не написал.
LVV>из поля Parm в операторе JCL exec
Параметры оператора DD я еще как-то могу перечислить, а вот EXEC... Впрочем, PARM — это, ЕМНИП, предшественник args.
LVV>Самая короткая была в составе СУБД ИНЕС (разработчик тот самый Михаил Донской).
Не поверишь, я видел живую ИНЕС. Поработать с ней, правда, я не успел.
LVV>Мне удалось сократить на 1 команду — 42 команды. LVV>Гордился страшно...
Было чем. Я Ассемблера ЕС ЭВМ не знаю. На PC кое-что делал на Ассемблере, да. Хорошо помню борьбу за каждый байт памяти. Точнее, за параграф.
Re[3]: Самый интересный баг, с которым вы возились
Здравствуйте, Pzz, Вы писали:
Z>>про свои баги я умолчу... все это НИЧТО по сравнению с этим: 500-mile email
Pzz>Сказка, конечно. Скорость распостранения сигнала в проводах заметно меньше скорости света.
в проводах как-раз таки и нет задержки. это не оптика.
In P=NP we trust.
Re[2]: Самый интересный баг, с которым вы возились
Козлы. Ещё в win95-2000 был баг, связанный с переписыванием строки конфигурирования ком-порта, отдаваемой в BuildCommDCB.
По возвращении из функции строка была той же самой, но внутри она подвергалась изменению туда-обратно (видимо, токенизатор временно заменял пробелы на нули).
Естественно, в 95 виндах и VC5 с никакой защитой памяти это работало отлично (хотя, вероятно, можно было организовать гонку в многопоточном приложении).
А в NT с треском вылетало, поскольку VC6 (или VC7, за давностью лет уже не помню) стал помещать строковые литералы в секцию констант, а загрузчик помещал секцию констант в readonly-страницы.
Лечилось или ключиком компилятора (помещать литералы в readwrite-секцию), или переходом на XP.
Перекуём баги на фичи!
Re[5]: Самый интересный баг, с которым вы возились
Здравствуйте, abibok, Вы писали:
Pzz>>>Сказка, конечно. Скорость распостранения сигнала в проводах заметно меньше скорости света. DM>>в проводах как-раз таки и нет задержки. это не оптика.
A>
что вас удивляет? что в проводе скорость распространения сигнала равна С или что в оптическом кабеле она существенно ниже?
ну и наконец такой пикантный момент... который автор не учел, сочиняя эту историю... чтобы узнать, что связь установлена, надо не только чтобы сигнал дошел туда, но и чтобы вернулся назад. за 3 миллисекунды можно только 250 миль покрыть. причем в режиме "солнечного зайчика" — пустили туда волну, отразили назад. TCP соединение сильно более сложная вещь, надо учитывать и скорость передачи данных, и время ее обработки и всякие коммутаторы по пути.
In P=NP we trust.
Re[3]: Самый интересный баг, с которым вы возились
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Mr.Delphist, Вы писали:
MD>>http://windowsasusual.blogspot.ru/2013/05/detective-story-sendto-and-10014.html
К>Козлы. Ещё в win95-2000 был баг, связанный с переписыванием строки конфигурирования ком-порта, отдаваемой в BuildCommDCB. К>По возвращении из функции строка была той же самой, но внутри она подвергалась изменению туда-обратно (видимо, токенизатор временно заменял пробелы на нули).
Феерично! Видимо, когда горе-автору указали на недопустимость изменения пользовательских данных, он сделал фикс в стиле "скопировать в безопасное место, прокатать токенизатор на оригинале, восстановить из безопасного места"
А то и вообще фикс был не авторский, поэтому было принято решение "чем меньше вмешательства в существующий код, тем лучше".
Коллега как-то тоже спотыкался о какую-то гонку в COM-портах, в силу чего не всегда была возможность добиться от ОС корректного освобождения ресурса (в итоге требовалась перезагрузка). Саппорт MS пожал плечами в стиле "проблему подтверждаем, но пока никто не жаловался, патча нет".
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
Компиляторский баг...
при включенной оптимизации выкидывал целые ветки проверок 'if a > b',
хотя a и b были внешними параметрами. И пока не нашел решения, как только отключить оптимизацию...
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
В одной из embedded платформ менеджер памяти (Alloc/Free) запускался после статической инициализации C++ кода.
Поэтому когда нашелся индус (в прямом смысле) который в конструкторе сделал неявный вызов Alloc, а другой индус сделал синглтон (со статическим мембером) — платформа намертво легла после интеграции.
Одновременно интегрировалось большое количество кода из разных команд, а отладчиков уровня загрузки тогда не было. Все что имелось — код ошибки арма: null-pointer-dereferencing, без указания адреса/стека.
Две недели вычитывали ВЕСЬ код, пока не раскрутили цепочку выполнения в уме до этого Alloc...
Re[5]: Самый интересный баг, с которым вы возились
Здравствуйте, abibok, Вы писали:
D>>Ковыряние в багах не имеет никакого отношения к решению задач. Прямо наоборот: оно отнимает время от этих самых задач и, соответственно, лишает удовлетворения от создания нового функционала.
A>Умение быстро понять причину сложного бага — это показатель аналитических способностей и квалификации. Отладка интересного бага, завершившаяся победой, дает азарт и удовлетворение почище чем кодинг.
Иногда. Вот если совмещать хороший кодинг и баг-фиксинг, ваще айс
Re[2]: Самый интересный баг, с которым вы возились
Здравствуйте, k55, Вы писали:
k55>Начали копать код (код не наш, а производителя дров) выяснилось что там есть таблица температур начинающася с 20 градусов. k55>И кривой код который находил первое вхождение, брал индекс и вычитал 1 и брал вторую границу. k55>В нашем случае получался индексы 0 и -1. Ну а дальше после вычислений получалось что HDD перегрелся и система его честно выключала.
В качестве исправления достаточно в таблице температур прописать -200°С первым ключом. (Если весь азот замёрзнет, то приставке будет пофиг), а дальше пусть сразу +21, +22 и т.д.
DM>ну и наконец такой пикантный момент... который автор не учел, сочиняя эту историю... чтобы узнать, что связь установлена, надо не только чтобы сигнал дошел туда, но и чтобы вернулся назад. за 3 миллисекунды можно только 250 миль покрыть. причем в режиме "солнечного зайчика" — пустили туда волну, отразили назад. TCP соединение сильно более сложная вещь, надо учитывать и скорость передачи данных, и время ее обработки и всякие коммутаторы по пути.
Там все настолько непросто, что вряд ли кто-то один знает конкретную картину.
В пределах одного датацентра (физического здания) round trip time обычно в районе 500 мкс (от 300 до 600, если на пути 1-2 роутера). Что уже вычитает примерно 150 км. "скорости света" из расчётов того фантазёра про скорость света и email.
Для ethernet соединения через "медные трубы" если соединена одна машина с другой можно добиться 6 мкс. при payload в несколько байт на 1 Гбит/с соединении. Занятно, что 10 Гбит будет медленнее, если payload меньше 64 байт. Оптика будет еще медленнее... в общем, господа, low latency — мир, полный странностей и неожиданностей.
PS: числа приведены для специально оптимизированных машин — обычные две машины, воткнутые друг в друга ethernet'ом, дадут 150-200 мкс. для ICMP.
Так что история, конечно, красивая, но явно вранье.
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
Из совсем свежего.
Win7. Есть прилада, довольно сырая и иногда падает. Есть сервис, который приладу стартует, следит за ней, и при надобности перезапускает.
Часть прилады — компонента от third party (исходников нет); что именно она делает, неважно (для порядку: следит за состоянием сети и информирует клиента о важных изменениях).
Компоненту перенесли в сервис. В релизе все прекрасно, в дебаге прилада не стартует (CreateProcess проходит успешно, но созданный процесс заканчивается, не успев начаться, не исполнив ни одной инструкции, с кодом 0xc00000a5).
Я не настоящий сварщик windows programmer; починить-то починил, но починка стоила мне нескольких седых волос. Интересно, как настоящие сварщики ее бы решали.
Re[3]: Самый интересный баг, с которым вы возились
Здравствуйте, Кодт, Вы писали:
К>В качестве исправления достаточно в таблице температур прописать -200°С первым ключом. (Если весь азот замёрзнет, то приставке будет пофиг), а дальше пусть сразу +21, +22 и т.д.
Хорошая идея. Надо будет предложить коллеге который правил код.
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
Здравствуйте, abibok, Вы писали:
A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.
Наше приложение скомпилированное VS 2010 падало. До тех пор пока кто-то, как-то , не понятно зачем решил скомпилировать
проект с ключем <linkflags>/NXCOMPAT:NO
Ну вот кто знал ? Кто знал ? Промудохкались 2 дня с проблемой
(ну или я не помню уже)
Перекуём баги на фичи!
