Козлы. Ещё в win95-2000 был баг, связанный с переписыванием строки конфигурирования ком-порта, отдаваемой в BuildCommDCB.
По возвращении из функции строка была той же самой, но внутри она подвергалась изменению туда-обратно (видимо, токенизатор временно заменял пробелы на нули).
Естественно, в 95 виндах и VC5 с никакой защитой памяти это работало отлично (хотя, вероятно, можно было организовать гонку в многопоточном приложении).
А в NT с треском вылетало, поскольку VC6 (или VC7, за давностью лет уже не помню) стал помещать строковые литералы в секцию констант, а загрузчик помещал секцию констант в readonly-страницы.
Лечилось или ключиком компилятора (помещать литералы в readwrite-секцию), или переходом на XP.
Перекуём баги на фичи!
Re[4]: Самый интересный баг, с которым вы возились
Pzz>>Сказка, конечно. Скорость распостранения сигнала в проводах заметно меньше скорости света. DM>в проводах как-раз таки и нет задержки. это не оптика.
Re[4]: Самый интересный баг, с которым вы возились
D>Ковыряние в багах не имеет никакого отношения к решению задач. Прямо наоборот: оно отнимает время от этих самых задач и, соответственно, лишает удовлетворения от создания нового функционала.
Умение быстро понять причину сложного бага — это показатель аналитических способностей и квалификации. Отладка интересного бага, завершившаяся победой, дает азарт и удовлетворение почище чем кодинг.
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 пожал плечами в стиле "проблему подтверждаем, но пока никто не жаловался, патча нет".
Re[6]: Самый интересный баг, с которым вы возились
DM>что вас удивляет? что в проводе скорость распространения сигнала равна С?
Всегда равняется или для разных материалов изоляции все-таки она разная? Для всех частот скорость распространения волнового пакета одинакова или все-таки нет? Радиоволна будет двигаться с одинаковой скоростью в вакууме и в меди, или все-таки нет? Чем отличается скорость фазовая от скорости групповой и какая их них имеется в виду, когда мы говорим о передаче сигнала? А почему? Как связана скорость передачи сигнала со скоростью движения электронов? А фотонов? Что такое С и каков физический смысл этой величины? А можно ли двигаться быстрее С?
Рассуждайте лучше про веру и бога, а не о физике, там неудобных вопросов некому задавать.
Делаем ТВ приставки.
Однажды провайдер пришел с проблемой у клиентов в домах некоторые приставки стали терять HDD.
Долго понять не могли. У провайдера в лабах не воспроизводится. У нас не воспроизводится. А в домах воспроизводится.
Грешили на перегрев HDD, мол клиенты ставят у батарей или еще где, зима же.
Тем временем число жалоб от конечных поьлзователей начало возрастать.
Провайдер начал мониторить HDD на все приставках, вести статистику. В итоге он вывел закономерность что отключались HDD у которых температура была ниже 20 градусов по Цельсию.
Мы тут дружно в голос — "ЗАМЕРЗАЮТ"
Начали копать код (код не наш, а производителя дров) выяснилось что там есть таблица температур начинающася с 20 градусов.
И кривой код который находил первое вхождение, брал индекс и вычитал 1 и брал вторую границу.
В нашем случае получался индексы 0 и -1. Ну а дальше после вычислений получалось что HDD перегрелся и система его честно выключала.
Ну и понятно почему никто не смог воспроизвести кроме клиентов, т.к. температура в лабах выше 20 градусов. Да и приставки обычно всегда работают т.е. теплые.
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
Здравствуйте, 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 дня с проблемой
Перекуём баги на фичи!
