Здравствуйте, zaufi, Вы писали:

Z>про свои баги я умолчу... все это НИЧТО по сравнению с этим: 500-mile email

Сказка, конечно. Скорость распостранения сигнала в проводах заметно меньше скорости света.

Я в свое время так тоже развлекался, тока соединял два номера, как будто они звонят друг другу... Такой вот Call-ID Купидон х)

Еще был замечательный "баг" от Microsoft до сих пор работает. Выдает при установке драйвера пользователю какой-то дурацский диалог — а хотите ли поставить не подписанный драйвер... а подпись только в MS делается, да и еще за деньги... Исправили перехватом функций из Kernel в памяти, вставив jmp на успешную проверку перед вызовом диалога... Теперь устанавливается не подписанный без глупых вопросов...

Здравствуйте, abibok, Вы писали:

A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.

1. http://rsdn.ru/forum/humour/5096566

Автор: Eugeny__
Дата: 11.03.13

2. Баг jvm в лохматые годы, происходящий строго в определенном месте выполнения(результат расследования)
3. Баг(или фича) компилятора Скалы, который давал NPE там, где его ну вообще никак быть не должно. Краткая суть после расследования:
жаба-код

//some code
Integer value;
// code
SomeClass someInstance = new SomeClass()
someInstance.do(value) // 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). Естественно, вводил для теста мастер-ключа одинаковые цифры, чтобы не забыть, ибо если забыть мастер-ключ, то пинпад можно выкидывать(или везти в сертифицированный сервис в Германии для разблокировки). Хрен там — ошибка, и все. После долгой переписки с местным сервисом, и их переписки с производителем, выяснилось, что команды я шлю абсолютно верные, но пинпаду не нравится простота мастер-ключа: ему подавай что-то посложнее! Сгенерил рандомку, записал ее, ввел — все заработало...

Что-то еще было, может, напишу.

Здравствуйте, 0x8000FFFF, Вы писали:

FFF>Еще был замечательный "баг" от Microsoft до сих пор работает. Выдает при установке драйвера пользователю какой-то дурацский диалог — а хотите ли поставить не подписанный драйвер... а подпись только в MS делается, да и еще за деньги... Исправили перехватом функций из Kernel в памяти, вставив jmp на успешную проверку перед вызовом диалога... Теперь устанавливается не подписанный без глупых вопросов...

Ты шутишь ?

Здравствуйте, 0x8000FFFF, Вы писали:

FFF>Еще был замечательный "баг" от Microsoft до сих пор работает. Выдает при установке драйвера пользователю какой-то дурацский диалог — а хотите ли поставить не подписанный драйвер... а подпись только в MS делается, да и еще за деньги... Исправили перехватом функций из Kernel в памяти, вставив jmp на успешную проверку перед вызовом диалога... Теперь устанавливается не подписанный без глупых вопросов...

Сурово. И как оно, работает в виндах с последними апдейтами? Антивири не верещат на такую крамоль?

Здравствуйте, Eugeny__, Вы писали:

E__>Здравствуйте, 0x8000FFFF, Вы писали:

FFF>>Еще был замечательный "баг" от Microsoft до сих пор работает. Выдает при установке драйвера пользователю какой-то дурацский диалог — а хотите ли поставить не подписанный драйвер... а подпись только в MS делается, да и еще за деньги... Исправили перехватом функций из Kernel в памяти, вставив jmp на успешную проверку перед вызовом диалога... Теперь устанавливается не подписанный без глупых вопросов...

E__>Сурово. И как оно, работает в виндах с последними апдейтами? Антивири не верещат на такую крамоль?

Нет... :)) Уже 10 лет как х)

Здравствуйте, abibok, Вы писали:

A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.

Нету в багах ничего интересного.

Здравствуйте, Kubyshev Andrey, Вы писали:

KA>Здравствуйте, 0x8000FFFF, Вы писали:

FFF>>Еще был замечательный "баг" от Microsoft до сих пор работает. Выдает при установке драйвера пользователю какой-то дурацский диалог — а хотите ли поставить не подписанный драйвер... а подпись только в MS делается, да и еще за деньги... Исправили перехватом функций из Kernel в памяти, вставив jmp на успешную проверку перед вызовом диалога... Теперь устанавливается не подписанный без глупых вопросов...

KA>Ты шутишь ?

Нет х) Уже 10 лет как работает подмена в памяти процесса исполняемого кода kernel32.dll x) Кто же защитит — все же в usermode...

D>Нету в багах ничего интересного.

Это говорит о том, что решаемые по работе задачи — тоска и рутина. В интересных проектах и баги интересные.
А еще это хороший вопрос на интервью, хорошо помогает выйти на разговор с кандидатом.

Здравствуйте, abibok, Вы писали:

D>>Нету в багах ничего интересного.

A>Это говорит о том, что решаемые по работе задачи — тоска и рутина. В интересных проектах и баги интересные.
A>А еще это хороший вопрос на интервью, хорошо помогает выйти на разговор с кандидатом.

Ковыряние в багах не имеет никакого отношения к решению задач. Прямо наоборот: оно отнимает время от этих самых задач и, соответственно, лишает удовлетворения от создания нового функционала.

Здравствуйте, LaptevVV, Вы писали:

LVV>Вдохновленный таким напутствием сел я и карандашиком на бумаге расписал выполнение всех 22 команд за несколько шагов цикла.

Непонятно, звчем тебе напутствие понадобилось. На ЕС ЭВМ это был самый действенный метод отладки. Одно условие — нельзя было ничего пропускать, типа "а тут все понятно".

Здравствуйте, Privalov, Вы писали:

P>Здравствуйте, LaptevVV, Вы писали:

LVV>>Вдохновленный таким напутствием сел я и карандашиком на бумаге расписал выполнение всех 22 команд за несколько шагов цикла.

P>Непонятно, звчем тебе напутствие понадобилось. На ЕС ЭВМ это был самый действенный метод отладки. Одно условие — нельзя было ничего пропускать, типа "а тут все понятно".
На ЕС ЭВМ, помнится, все гонялись за книгой о дампах памяти...
Которые позиционировались как средство отладки...
Хотя на ЕС писали практически только на Фортране и PL-1...

Здравствуйте, LaptevVV, Вы писали:

LVV>На ЕС ЭВМ, помнится, все гонялись за книгой о дампах памяти...
LVV>Которые позиционировались как средство отладки...

Об этом только слышал от старших. Но говорили, что дампы — это крайнее средство для особо тяжелых случаев. Машинного времени, опять же, вечно не хватало.

LVV>Хотя на ЕС писали практически только на Фортране и PL-1...

На Коболе и на Ассемблере. О софте на Коболе я упоминал как-то. Видел пару лет назад. Дата выпуска — 1974 год.

Пока писал, вспомнил историю, может, даже по теме.
Замена ЭВМ на компьютеры у нас шла медленно и с опозданием. Поэтому о ЕС ЭВМ, о перфокартах, о дележе машинного времени я не только слышал.
Пришла к нам на ВЦ очередная версия одной софтины. Добавили к ней разработчики одну операцию, о времени выполнения которой ничего нигде не было сказано. Выделили на нее на всякий случай полтора часа. Запустили, стали ждать.
Через полтора часа приходят забирать машину. А она работает, лампочками подмигивает.
Позвали системщиков. Говорят, зациклилась. Те посмотрели, говорят, нет, машина работает штатно.
В общем, продлилось это все около трех часов. задача успешно завершилась.
Через несколько месяцев получили мы обновление этой софтины. Выделили нам время на долгоиграющую операцию. Запустили, собрались пойти перекусить. Вдруг девочки-операторы из смены прибегают, говорят, что задача закончилась. Думали, упала. Посмотрели протоколы — все нормально. Работала программа вместо трех часов что-то около минуты.
Несколько позже мы нашли библиотеку исходников. Оказалось, что написана эта программа была на Ассемблере.

Здравствуйте, abibok, Вы писали:

A>Какой баг запомнился больше всего? Не по трудоемкости, а скорее по интересности.

1. std::string Name = Node.getName();

На таком банальном коде приложение валилось с ошибкой, как это ни странно.
С getName было все в полном порядке, падение было именно в std::string, причем падало
только внутри одной функции, при специфических условиях. После долгого "разматывания"
исходников, включая многочисленные сторонние библиотеки, а также опций сборки, оказалось,
что некто пошаманил с препроцессором и опциями выравнивания данных, еще до подключения
проектом общих глобальных заголовков. Как писал потом автор "идеи", это было сделано в
целях что-то там оптимизировать в плане сериализации данных, передающихся по сети.

2. Настраивал удаленный доступ к компьютеру.

Там было что-то вроде TeamViewer-а, только с очень упрощенной функциональностью.
Настроил все, надо бы проверить. Запускаю виртуальную машину, включаю в ней интернет,
через RDP подключаюсь к специально выделенному для тестов компьютеру. На этом компьютере
запускаю программу-клиент для удаленного доступа и вбиваю в нее IP своего компа...
И здесь вдруг появляется забавный эффект — подключившись, я вижу свой десктоп с окном
запущенного RDP-сеанса, а в нем — десктоп тестового компа, на котором снова отображается
окно RDP-сеанса, только поменьше, а в нем опять десктоп тестового компа, еще меньше, и т.д.
И так они завораживающе открываются друг в друге, открываются медленно, одно за другим,
уходя все дальше вглубь, в бесконечность, а у моей Windows тут начинается жуткий своппинг,
тормоза, шуршание жесткого диска... Но я не мог остановиться и сидел зачарованный, пока
все окончательно не заглючило и систему пришлось перезагружать.

3. Баг примечателен в первую очередь своей психологической подоплекой.

Он появлялся фантомно, исключительно в релизных сборках и исключительно во время всяких важных
презентаций у начальства. Его выслеживали "с фонарями" в течение нескольких месяцев, с помощью
логов, крэш-дампов, отчетов, спец. билдов и прочих техник. Но самое прикольное, что почему-то
за многие месяцы никто не занялся этим багом вплотную, надеясь, что "партизанская" война и
выслеживание вот-вот дадут свои плоды. То есть, вместо того, чтобы сесть и починить, все
негласно ждали, пока какой-нибудь очередной крэш-дамп не зафиксирует точно проблемное место и
все будет кончено. Так длилось месяцами. В конце концов баг "обнаглел" и стал ронять систему
все чаще и чаще, как бы заявляя о себе, пока однажды один из сотрудников не "разозлился" на
него и со злости нашел и пофиксил его минут за 15 (там просто отсутствовала проверка на NULL).

Было это вообще давно ... тогда ещё 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 команды.
Гордился страшно...

Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>Может не самый интересный, но текст под рукой. Писали на PC XT, понадобились чтение с диска и запись на диск.
Писал на контроллере обмен с диском. Подпрограмма записи/чтения сектора. В ПЗУ работала без проблем. В ОЗУ не успевала после определения готовности выбора сектора читать/писать. Баг выловил быстро, но удивление не проходило. Там тупо стоял цикл на саму себя на команде готовности, а команда чтения была следующей за определением готовности.

Здравствуйте, LaptevVV, Вы писали:

LVV>Русский был Кобол
LVV>Программа выглядела почти как просто текст: Сложить, вычислить, вызвать...

Я видел русский Кобол. ЕМНИП, там с падежами проблемы. Несколько неудобно читать. А "нормальный" Кобол я видел сравнительно недавно. Мне структуры присылали для разбора. DATA DIVISION, верно? Документации с середины 70-х так никто и не написал.

LVV>из поля Parm в операторе JCL exec

Параметры оператора DD я еще как-то могу перечислить, а вот EXEC... Впрочем, PARM — это, ЕМНИП, предшественник args.

LVV>Самая короткая была в составе СУБД ИНЕС (разработчик тот самый Михаил Донской).

Не поверишь, я видел живую ИНЕС. Поработать с ней, правда, я не успел.

LVV>Мне удалось сократить на 1 команду — 42 команды.
LVV>Гордился страшно...

Было чем. Я Ассемблера ЕС ЭВМ не знаю. На PC кое-что делал на Ассемблере, да. Хорошо помню борьбу за каждый байт памяти. Точнее, за параграф.

Здравствуйте, Pzz, Вы писали:

Z>>про свои баги я умолчу... все это НИЧТО по сравнению с этим: 500-mile email

Pzz>Сказка, конечно. Скорость распостранения сигнала в проводах заметно меньше скорости света.

в проводах как-раз таки и нет задержки. это не оптика.