Бывало ли у вас, что вы безуспешно пытаетесь найти баг, не получается, в конце концов отчаиваетесь и решаетесь на это забить?
У меня за 15 лет разработки моего проекта это было, насколько я помню, два раза. Я думаю – может это баги в Delphi? Тогда уж наверно ничего не поделаешь, разве что написать для пользователей инструкцию – “не делайте так-то, это вызывает проблемы”.

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

K>Бывало ли у вас, что вы безуспешно пытаетесь найти баг, не получается, в конце концов отчаиваетесь и решаетесь на это забить?

Не было. Один раз искал баг в драйвере 2 месяца, но таки нашел.
В ядре Linux кстати недавно пофиксили баг который воспроизводится раз в несколько месяцев стресс-тестов.

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

K>Бывало ли у вас, что вы безуспешно пытаетесь найти баг, не получается, в конце концов отчаиваетесь и решаетесь на это забить?
Не было. Было, что баг искал несколько месяцев, было, что в итоге находил багу во фреймворке или даже в SQL Server. Но чтобы совсем не нашёл — такого не было.

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

K>Бывало ли у вас, что вы безуспешно пытаетесь найти баг, не получается, в конце концов отчаиваетесь и решаетесь на это забить?
K>У меня за 15 лет разработки моего проекта это было, насколько я помню, два раза. Я думаю – может это баги в Delphi? Тогда уж наверно ничего не поделаешь, разве что написать для пользователей инструкцию – “не делайте так-то, это вызывает проблемы”.

Не припомню. Если баг находтся в моем проекте/сфере ответственности, то это как незакрытый гештальт для меня — создает дискомфорт. Единственное исключение, если баг находится в проприетарной библиотеке без исходных кодов. Тогда удовлетворюсь тем, что нахожу условия при которых он воспроизводится и придумываю обходной путь. Но если это опенсорс, то полезу в исходники. Мой первый пост на этом форуме, кстати, создан под впечатлением от одного такого расследования — нашел заковыристую ошибку с thread stack guard page hit в дельфиском EurekaLog.

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

K>Бывало ли у вас, что вы безуспешно пытаетесь найти баг, не получается, в конце концов отчаиваетесь и решаетесь на это забить?
K>У меня за 15 лет разработки моего проекта это было, насколько я помню, два раза. Я думаю – может это баги в Delphi? Тогда уж наверно ничего не поделаешь, разве что написать для пользователей инструкцию – “не делайте так-то, это вызывает проблемы”.

Такое бывает с гейзенбагами, когда ошибка воспроизводится не всегда при одних и тех же шагах, что например вызвано условиями гонки или дедлоками потоков или БД-транзакций. Чтобы такой баг починить, нужно этими компетенциями обладать, чтобы увидеть в коде такую проблему даже без воспроизведения бага.

А какие средства были использованы для поиска бага?

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

AD>А какие средства были использованы для поиска бага?

Обычные средства Delphi: установка чекпоинта в нужном месте кода, пошаговая отладка, средства для просмотра значений переменных во время отладки и т.д. Я на знаю, какие средства отладки используются в других языках.

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

K>Бывало ли у вас, что вы безуспешно пытаетесь найти баг, не получается, в конце концов отчаиваетесь и решаетесь на это забить?

Нет. В конце концов, все налаживалось. Иногда это занимало очень много времени.

K>У меня за 15 лет разработки моего проекта это было, насколько я помню, два раза. Я думаю – может это баги в Delphi? Тогда уж наверно ничего не поделаешь, разве что написать для пользователей инструкцию – “не делайте так-то, это вызывает проблемы”.

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

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

K>Обычные средства Delphi: установка чекпоинта в нужном месте кода, пошаговая отладка, средства для просмотра значений переменных во время отладки и т.д. Я на знаю, какие средства отладки используются в других языках.



Т.е. баг воспроизводился в отладке и его не удалось исправить? Для меня это анрил. Я-то подумал, что речь о багах, которые воспроизводиться у пользователя раз в год и причину которых проще отнести к переключению ячейки памяти компа из-за попадания нейтрино из окрестностей чёрной дыры

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

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

K>>Обычные средства Delphi: установка чекпоинта в нужном месте кода, пошаговая отладка, средства для просмотра значений переменных во время отладки и т.д. Я на знаю, какие средства отладки используются в других языках.

AD>

AD>Т.е. баг воспроизводился в отладке и его не удалось исправить? Для меня это анрил. Я-то подумал, что речь о багах, которые воспроизводиться у пользователя раз в год и причину которых проще отнести к переключению ячейки памяти компа из-за попадания нейтрино из окрестностей чёрной дыры

У меня в данном случае, из-за которого я написал этот пост, ошибка срабатывает на сторонних компонентах Delphi — VCL. Если это не баг Delphi, по идее наиболее вероятно что программа где-то пишет данные в динамический массив и выходит за его пределы. В Delphi нет проверок выхода за границы динамического массива, понятно что их и не должно быть из-за скорости. В последнее время я использую собственные динамические массивы на основе "статических классов" с дженериками, в которых есть проверка выхода за границы, но не сформировалась привычка всегда их использовать, опять же из-за скорости.

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

K>Бывало ли у вас, что вы безуспешно пытаетесь найти баг, не получается, в конце концов отчаиваетесь и решаетесь на это забить?
K>У меня за 15 лет разработки моего проекта это было, насколько я помню, два раза. Я думаю – может это баги в Delphi? Тогда уж наверно ничего не поделаешь, разве что написать для пользователей инструкцию – “не делайте так-то, это вызывает проблемы”.

История длиною в лет пять как минимум думаю, а может и даже больше
Был у нас баг, который приводил к синему экрану.

Переписывали весь код, проверили с 146% покрытием, но иногда у клиентов проскакивал.
Было "решение" в виде отключения функциональности и наша поддержка быстро это делала, а снимок памяти к нам так и не доходил.

В общем забили на проблему пока наконец не пришёл снимок памяти, и выяснилось что мы запускали 32-битный код в 64-битном процессе
А всё потому, что имелось 2 (ДВЕ) почти одинаковые функции определения архитектуры процесса.
Но они всё таки немного отличались и в итоге неправильно иногда определяли архитектуру.

Вывод, иногда стоит просто оставить и пойти за пивом

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

K>В Delphi нет проверок выхода за границы динамического массива, понятно что их и не должно быть из-за скорости.

Да ты знаток:

program Project1;
{$APPTYPE CONSOLE}
{$RANGECHECKS ON}
uses
 System.SysUtils;
var
 a:array of byte;
begin
  try
   SetLength(a, 100);
   a[100] := 1;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
 ReadLn;
end.

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

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

K>>В Delphi нет проверок выхода за границы динамического массива, понятно что их и не должно быть из-за скорости.

R>Да ты знаток:
R>

program Project1;
R>{$APPTYPE CONSOLE}
R>{$RANGECHECKS ON}
R>uses
R> System.SysUtils;
R>var
R> a:array of byte;
R>begin
R>  try
R>   SetLength(a, 100);
R>   a[100] := 1;
R>  except
R>    on E: Exception do
R>      Writeln(E.ClassName, ': ', E.Message);
R>  end;
R> ReadLn;
R>end.

Спасибо, не знал. {$RangeChecks On} можно указать в головном модуль проекта, или придётся эту строку добавлять в каждый модуль?

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

K> Спасибо, не знал.

Поражает, как можно 15 лет пилить код и не знать о таких вещах...

K> {$RangeChecks On} можно указать в головном модуль проекта, или придётся эту строку добавлять в каждый модуль?

Для всего проекта это включается в настройках проекта (Delphi Compiler\Compiling\Runtime errors), директива в файле действует только на файл.

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

K>Бывало ли у вас, что вы безуспешно пытаетесь найти баг, не получается, в конце концов отчаиваетесь и решаетесь на это забить?
1) За последние примерно двадцать лет программирования, такое было у меня может пару-тройку раз.
2) Забить — никогда на такое не решился бы. Даже зная, что источник проблем — не мой код, а что-либо другое.

То есть — в любом случае предпринимаю шаги по решению проблемы. Однако, прежде всего, я пытаюсь проанализировать причину.
После мозгового штурма (детального анализа), часто раскрывается или суть проблемы, или пути её детальной диагностики.

K>Я думаю – может это баги в Delphi?
Пользуешься до сих пор Delphi

Тогда у меня даже нет слов...
Но и сочуствия также нет...

K>Тогда уж наверно ничего не поделаешь, разве что написать для пользователей инструкцию – “не делайте так-то, это вызывает проблемы”.

Совсем тупиковый путь.
Путь к потере Заказчика/Места_работы, возможности продвижения своего продукта.
ИМХО наиболее верно — найти причину проблемы и решить её "на_своём_уровне".

P.S. Раскрою понятие "на_своём_уровне" — поясню на двух примерах:
1) Разработаанное на C++, MFC наше Desktop application (работающее в диспетчерской службе в режиме 24/7)
падает (краш) в произвольные моменты времени. Обычно после 2...3 и более часов работы.

2) Я портровал приложение (C++, MFC) с MSVC2003 на MSVC2008.
После этого, при приёме по сети (UDP) данных от внешнего аппаратного контроллера, иногда наблюдалось UB (включая зависания или краш).

Анализ случая 1 показал, что имеет место утечка памяти. В наших кодах применялись smart-pointers, и проблем не было.
В то же время, замена третье-стороннего ActiveX компонента, на аналогичный (более новой версии) помогла решить проблему.

Анализ случая 2 выявил, что в некоторых пакетах от контроллера идут метки времени в виде переменных типа time_t.
Вот такие: https://en.wikipedia.org/wiki/Unix_time эти переменные сериализуются в последовательный битовый поток,
который передаётся в различные компоненты приложения.
Для MSVC2003 тип данных time_t содержит 4-ре байта, а для MSVC2008 — соответственно 8-мь байт.
Внесение корректировок в код приложения, позволило решить данную проблему.

Т.е. первый случай — это просто уровень замены готового внешнего компонента (черного ящика).
Второй случай — уровень доработок нашего (ранее разработанного) кода.

P.S. Описал случаи семи-восьми-летней давности. Сейчас, разрабатывая на Qt5, я не использую ни древних ActiveX компонентов,
ни старых типов данных. Посему, разработка и отладка приложений проходит намного проще.

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

AG> Пользуешься до сих пор Delphi
Как тысячи компаний во всем мире.

AG> Но и сочуствия также нет...
Для себя прибереги.

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

K>Бывало ли у вас, что вы безуспешно пытаетесь найти баг, не получается, в конце концов отчаиваетесь и решаетесь на это забить?
K>У меня за 15 лет разработки моего проекта это было, насколько я помню, два раза. Я думаю – может это баги в Delphi? Тогда уж наверно ничего не поделаешь, разве что написать для пользователей инструкцию – “не делайте так-то, это вызывает проблемы”.

Нет. Багов, которые невозможно поймать в отладчике, было много (типа, возникает у пользователя Х раз в неделю)
Но даже такие все равно ловятся логами, в том или ином виде. Просто логгирование должно быть достаточным.

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

R>Поражает, как можно 15 лет пилить код и не знать о таких вещах...

Так это же классно. Перед ТС ещё столько открытий в той области, где он давно уже обитает ))

Я бы порекомендовал ему погуглить и почитать о других средствах (доступных даже для дельфи), таких как например отладочные менеджеры памяти и генераторы крэш-репортов. Возможно он ещё кучу багов с помощью их найдёт

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

K>> {$RangeChecks On} можно указать в головном модуль проекта, или придётся эту строку добавлять в каждый модуль?

R>Для всего проекта это включается в настройках проекта (Delphi Compiler\Compiling\Runtime errors), директива в файле действует только на файл.

У меня вроде такой ошибки с динамическим массивом нет, а баг остался. Может быть у меня где-то код обращается к свойству класса, который не инициализирован или который финализирован? Я не помню, по умолчанию такие ошибки срабатывают? Можно ли включить их проверку?

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

AD>Я бы порекомендовал ему погуглить и почитать о других средствах (доступных даже для дельфи), таких как например отладочные менеджеры памяти и генераторы крэш-репортов. Возможно он ещё кучу багов с помощью их найдёт

Сходу не нагуглил, можно в двух словах, что это такое? Менеджер памяти — это что-то вроде моего сборщика мусора

Автор: Khimik
Дата: 05.05.19

? А что такое креш-репорт и есть ли это в Delphi?

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

K> У меня вроде такой ошибки с динамическим массивом нет, а баг остался. Может быть у меня где-то код обращается к свойству класса, который не инициализирован или который финализирован? Я не помню, по умолчанию такие ошибки срабатывают? Можно ли включить их проверку?

Нет, такие ошибки автоматически не ловятся. Если у твоих объектов есть общий предок, можно в нем перекрыть метод FreeInstance и самостоятельно очищать освобождаемую память, это поможет отловить обращения к освобожденным объектам. А можно просто взять менеджер памяти FastMM и активировать в нем необходимые опции для отладки (FastMM4Options.inc).

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

K>Бывало ли у вас, что вы безуспешно пытаетесь найти баг, не получается, в конце концов отчаиваетесь и решаетесь на это забить?

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

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

K>Бывало ли у вас, что вы безуспешно пытаетесь найти баг, не получается, в конце концов отчаиваетесь и решаетесь на это забить?

однажды мне попался злющий баг, на который я безуспешно потратил неделю.
потом лучшие умы нашей команды навалились на него все сразу, вчетвером мы угрохали на это ещё неделю-другую.
баг оказался из-за нарушения ODR, причём это было в легаси-коде пятнадцатилетней давности.
при тогдашнем компиляторе всё работало, а современный тихо и без шума генерил глючный код (имеет право, тут без претензий).

другой баг на этом же проекте отнял ещё больше времени.
воспроизводился он крайне странно: порой один раз из двухсот попыток, порой сериями по несколько раз подряд.
в итоге удалось его локализовать — корни ушли в системную библиотеку Xbox One.
"хакерскими" методами удалось его обойти, но майкрософт это не заапрувил (тут претензии уже есть).
баг в итоге остался, ушёл в продакшен, но я хотя бы могу с чистой совестью страдания пользователей не принимать на свой счёт.

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

K>Сходу не нагуглил

Не верю, что ничего не нагуглилось. Тут в соседнем ответе уже подсказали одно из средств.

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

K>Бывало ли у вас, что вы безуспешно пытаетесь найти баг, не получается, в конце концов отчаиваетесь и решаетесь на это забить?

Ну не так чтобы совсем забить, не было, но было что баг я за какое-то время найти не смог, он случался крайне редко и только на стресс-тестах и при этом дополнительное логгирование еще уменьшало его вероятность. Ну т.е. скорее всего data races где-то были. В какой-то момент он исчез, скорее всего был пофикшен в результате рефакторинга. Я даже примерно подозреваю, какое именно изменение его пофиксило, но откатив только его, я все равно не смог его воспроизвести за приемлимое время, чтобы быть на 100% уверенным.
Я считаю что это ничья

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

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

K>> У меня вроде такой ошибки с динамическим массивом нет, а баг остался. Может быть у меня где-то код обращается к свойству класса, который не инициализирован или который финализирован? Я не помню, по умолчанию такие ошибки срабатывают? Можно ли включить их проверку?

R>Нет, такие ошибки автоматически не ловятся. Если у твоих объектов есть общий предок, можно в нем перекрыть метод FreeInstance и самостоятельно очищать освобождаемую память, это поможет отловить обращения к освобожденным объектам.

У всех моих объектов действительно есть общий предок, но я не понял вашу идею. Как может ручное очищение памяти быть полезным, чтобы определить, обращался ли кто-то к этой памяти после очищения?

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

K> У всех моих объектов действительно есть общий предок, но я не понял вашу идею. Как может ручное очищение памяти быть полезным, чтобы определить, обращался ли кто-то к этой памяти после очищения?

Смысл в том, чтобы поля освобожденного объекта имели недопустимые значения. Простой пример:

program Project1;
{$APPTYPE CONSOLE}
uses
  System.SysUtils;
type
 TObj = class(TObject)
  FString : string;
  procedure FreeInstance; override;
 end;
procedure TObj.FreeInstance;
begin
 CleanupInstance;
// FillChar(Pointer(Self)^, InstanceSize, $EF);
 FreeMem(Pointer(Self));
end;
begin
  try
   var obj := TObj.Create;
   obj.FString := 'hello';
   writeLn('"', obj.FString, '"');
   obj.Free;
   writeLn('"', obj.FString, '"');
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
 readln;
end.

Сначала запусти как есть, потом раскомментируй FillChar и запусти снова.

K>Бывало ли у вас, что вы безуспешно пытаетесь найти баг, не получается, в конце концов отчаиваетесь и решаетесь на это забить?

Нет.

K>У меня за 15 лет разработки моего проекта это было, насколько я помню, два раза. Я думаю – может это баги в Delphi? Тогда уж наверно ничего не поделаешь, разве что написать для пользователей инструкцию – “не делайте так-то, это вызывает проблемы”.

То есть вы даже сквозь один уровень не смогли прорваться? Мне доводилось пробираться сквозь уровни кода на языке программирования, через виртуальную машину для байткода, далее через контейнер, ядро ОС и в итоге баг таки был выявлен в BIOS. Причем такие расследования не то чтоб сложные, ибо баг воспроизводился сам по себе и с довольно высокой частотой/вероятностью.

Самые сложные баги — это те, которые сложно воспроизвести. Скажем, что-то, что случается на одной машине из 40 тысяч раз в неделю.

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

R>Сначала запусти как есть, потом раскомментируй FillChar и запусти снова.

InstanceSize это размер всех полей класса? Вашем пример не до конца корректный — заполняться значением $EF будет не вся строка FString, а только указатель на неё (само поле FString размером 4 байта)?

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

K> R>Сначала запусти как есть, потом раскомментируй FillChar и запусти снова.

K> InstanceSize это размер всех полей класса?

Да.

K> Вашем пример не до конца корректный — заполняться значением $EF будет не вся строка FString, а только указатель на неё (само поле FString размером 4 байта)?

Всю строку заполнять смысла нет. Тут главное именно в том, чтобы сделать поля невалидными.

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

Почитал ответы: почти все пишут, что не было такого, по 2 месяца ловят, но находят, и т.п. Стало интересно, раз все такие идеальные, то кто все те люди, которые поддерживают софт, у которого общеизвестные баги годами без движения висят?

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

УП>Почитал ответы: почти все пишут, что не было такого, по 2 месяца ловят, но находят, и т.п. Стало интересно, раз все такие идеальные, то кто все те люди, которые поддерживают софт, у которого общеизвестные баги годами без движения висят?

Они сюда не заходят, им стыдно.

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

УП>Почитал ответы: почти все пишут, что не было такого, по 2 месяца ловят, но находят, и т.п. Стало интересно, раз все такие идеальные, то кто все те люди, которые поддерживают софт, у которого общеизвестные баги годами без движения висят?

Это другое
И у меня есть баги которые годами лежат. Но если бы я таки слез с печи и взялся их чинить, то обязательно добил бы.

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

УП>Здравствуйте, Khimik, Вы писали:

УП>Почитал ответы: почти все пишут, что не было такого, по 2 месяца ловят, но находят, и т.п. Стало интересно, раз все такие идеальные, то кто все те люди, которые поддерживают софт, у которого общеизвестные баги годами без движения висят?
У багов может быть низкий приоритет и за них просто никто не берётся — все чинят более важное. Или стоимость починки большая. Такое может висеть до конца жизни системы.