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

Здравствуйте, 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 совпадали

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

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

про свои баги я умолчу... все это НИЧТО по сравнению с этим: 500-mile email
не знаю как у тебя с английским, русский пересказ если и есть то гугл поможет тебе найти %)
ничего более "зачетного" мне в реальной жизни не попадалось (ну или я не помню уже)

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

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

Был у меня баг, в системе предоплаченых звонков. Тестировал — путем звонка с системы(клиентом был мой ноут) — на свой мобильный. Ошибся в одной цифре — набирал не свой мобильный. Хотя ответ был, мой мобильник не звонил(естественно) — я ругался довольно 3-х этажным матом(до отбоя), и так раза 3. Потом когда понял, пот прошиб — где-то есть чувак с похожим на мой мобильный номером, ему приходит вызов с каллерид скажем "№№888№№№", где на него начинают орать матом. Долго смеялся, потом перезвонил — извенился, на той стороне от шока наверное ничего не поняли, чувак говорил — что ничего плохого не делал(видно подумал что я из кровавого КГБ).

пытался впомнить -- завис. Кто умеет могзовых багов отлаживать?

Если серьезно, то запомнился баг с shell скриптом: я полагался на тот факт, что после сортировки каких-либо строк, (какой бы ни была локаль) строки с одинаковым префиксом будут идти вместе.
Оказалось, что в не C locale эта "гарантия" может вероломно нарушаться.

А так как на этой сортировке была построена логика -- фактически я таким образом на шелле оперировал с деревьями, а строки были путями в дереве, то это аукалось нетривиальным образом черех километр от этого бага.

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

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

как-то когда тестировала приложение в томкате с 200 одновременными пользователями — обнаружила что система начинает намертво зависать в какой-то момент
оказался классический дедлок в томкате связанный с фиксированным количеством возможных тредов

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

Работал я на поддержке проекта с ядром на C++, который занимался выгрузкой и загрузкой данных в БД. Проект по большей части был написан американской командой (исходники этого периода не блещут высоким стилем, но понятны и работают), потом года на три отдан вьетнамцам. Вьетнамцы что-то пытались писать, но ожиданий не оправдали, и код передали нам.

Тестер пожаловалась, что в DB2 не загружаются данные в поля типа дата/время. Может быть, это был и не DB2 вовсе, детали уже позабылись, но сути это не меняет.

Судя по логам, в параметрах INSERT-выражений, передаваемых как строки, день был перепутан с месяцем. Задача выглядела простой. Найдя примерно следующий код

#define DB2_TIMESTAMP_FORMAT "YYYY-DD-MM hh:mm:ss"

я исправил его на

#define DB2_TIMESTAMP_FORMAT "YYYY-MM-DD hh:mm:ss"

и запустил билд в полной уверенности, что проблема решена. Но не тут-то было, ошибка никуда не делась.

Первой мыслью было, что я поменял не тот дефайн, но, продравшись через пять слоев абстракции, отладчик привел меня к строкам

if (db_type == DB_DB2)
  field_val = FormatTime(&time_val, DB2_TIMESTAMP_FORMAT);

и версия отпала. В недоумении я зашел внутрь FormatTime и узрел что-то вроде

char* FormatTime(tm *time_val, const char *format)
{
  char *formatted_time = new char[50];

  if (strcmp(format, "YYYY-DD-MM hh:mm:ss") == 0)
    strftime(formatted_time, 50, "%Y-%d-%m %H:%M:%S", time_val);
  else if (strcmp(format, "MM/DD/YYYY hh:mm:ss") == 0)
    strftime(formatted_time, 50, "%m/%d/%Y %H:%M:%S", time_val);
  else if (strcmp(format, "..."))
  ...

  return formatted_time;
}

Там был еще пяток else if с разными форматами, но моего среди них не было.

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

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

Не совсем баг.
После написания одной проги я обнаружил, что она слишком медленно работает. Я вставил функции определения времени и начал рефакторинг. Изменил программу — так же медленно. Еще изменил — то же. Хорошенько пораскинул мозгами, провел существенную оптимизацию, которая, по идее, должна была сократить время на порядок — прога по-прежнему работала как черепаха. Оказалось, время уходило на вызов процедур, возвращающих время, одна из которых была во внутреннем цикле.

Самый интересный баг, пожалуй, относится к тому времени, когда я работал над автоматизацией действий с GUI в Windows.

Если мне память не изменяет, программа внедрялась в приложение-"жертву", подгружая в него свою DLL и подменяя обработчик оконных сообщений. В программе были некие действия, которые должны были выполняться когда пользователь с приложением ничего не делает, то есть, не жмет на кнопки, не двигает мышью и т.д.

Выглядело это так: в очередь отправлялось наше оконное сообщение. Когда подходил его черед, обработчик смотрел, есть ли еще сообщения для интерфейсного потока, и если нет, то выполнял требуемые действия. Если есть, просто отправлял сообщение обратно в конец очереди, и процедура повторялась.

Это работало везде, кроме Гугл Хрома, и мне выпало разбираться, почему. Загрузив Хромиум и собрав его в дебаг-конфигурации, я погрузился в отладку.

В итоге выяснилось, что в Хроме реализован точно такой же механизм idle listener. Они тоже постили в очередь сообщение и смотрели, не претендует ли кто-то еще на обработку. Даже если пользователь ничего не делал, в списке всегда было наше сообщение, и Хром уступал ему. Обработчик нашего сообщения, в свою очередь, находил сообщение Хрома, и так они бесконечно расшаркивались перед дверью не в силах в нее войти.

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

G>В итоге выяснилось, что в Хроме реализован точно такой же механизм idle listener. Они тоже постили в очередь сообщение и смотрели, не претендует ли кто-то еще на обработку. Даже если пользователь ничего не делал, в списке всегда было наше сообщение, и Хром уступал ему. Обработчик нашего сообщения, в свою очередь, находил сообщение Хрома, и так они бесконечно расшаркивались перед дверью не в силах в нее войти.

И как исправили?

UA>И как исправили?

Сузили критерий для состояния простоя. В частности, перестали пропускать вперед все, что выше WM_USER.

А вот самый запоминающий ся баг, Эт в институте было — подошел я, значит, к аппарату кофе попить и мелочь ему всю спихнуть — сунул пять копеек и по кнопке случайно ударил и он бац — кофе самого дорого налил (за любую монетку оказываться наливал)!!! Ух и попил я тогда кофе и какао — халявое такое вкусное было.

G>Сузили критерий

То есть, расширили, но суть понятна

Помницца пришел нам от юзера репорт, написанный литературным языком и объемом этак на А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. Запись перестала работать.

Лазар

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

O>Помницца пришел нам от юзера репорт, написанный литературным языком и объемом этак на А4 страницу немелкого шрифта.. Начинался он так: "Здраствуйте уважаемые разработчики ?????, пишу я вам из библиотеки, так как после установки вашего продукта на мой компьютер ....". А что был за баг, уже не помню, он был неинтересным наверное. Да и времени дофига прошло, "продукт" тот как говорится завершил lifecycle. Зато письмо то запомнилось и фраза та до сих пор припоминается в нашем (да возможно и не только) тиме.

Напомнило

ПАСАНЫ НЕ КАЧАЙТЕ ТАМ ВИРУС КОМП СГОРЕЛ ПИШУ С ПУЛЬТА ОТ ТЕЛЕВИЗОРА

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

Виноват. Пытался внести баг в правильный код и сделал дополнительную ошибку. На самом деле было так:

EXT_PROC@    _doserror, __CDECL__

OPEN_CODE@    _DOS

PUB_PROC@    absread, __CDECL__

        mov    [byte ptr cs:exec+1], 25h        ; int 25h
        jmp    short begin@

PUB_PROC@    abswrite, __CDECL__

        mov    [byte ptr cs:exec+1], 26h        ; int 26h

STAT_SYM@    begin, label, near, __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

Лазар

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

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

Не моё, но история понравилась: http://www.rsdn.ru/forum/cpp/1479579

Автор: Dmi_3
Дата: 09.11.05

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м на бетон.
После замены битых дисков в массиве приложение снова работает.

Z>не знаю как у тебя с английским, русский пересказ если и есть то гугл поможет тебе найти %)

http://rauf.livejournal.com/23552.html