Здравствуйте, Khimik, Вы писали:
K> У меня вроде такой ошибки с динамическим массивом нет, а баг остался. Может быть у меня где-то код обращается к свойству класса, который не инициализирован или который финализирован? Я не помню, по умолчанию такие ошибки срабатывают? Можно ли включить их проверку?
Нет, такие ошибки автоматически не ловятся. Если у твоих объектов есть общий предок, можно в нем перекрыть метод FreeInstance и самостоятельно очищать освобождаемую память, это поможет отловить обращения к освобожденным объектам. А можно просто взять менеджер памяти FastMM и активировать в нем необходимые опции для отладки (FastMM4Options.inc).
Здравствуйте, Khimik, Вы писали:
K>Бывало ли у вас, что вы безуспешно пытаетесь найти баг, не получается, в конце концов отчаиваетесь и решаетесь на это забить?
Да наоборот, даже азарт просыпается на фоне унылой и тоскливой разработки или поддержке легаси. Т.е. можно сказать, что
это та самая романтика с чашкой кофе на ночь. Некий вызов, я бы даже сказал.
Здравствуйте, Khimik, Вы писали:
K>Бывало ли у вас, что вы безуспешно пытаетесь найти баг, не получается, в конце концов отчаиваетесь и решаетесь на это забить?
однажды мне попался злющий баг, на который я безуспешно потратил неделю.
потом лучшие умы нашей команды навалились на него все сразу, вчетвером мы угрохали на это ещё неделю-другую.
баг оказался из-за нарушения ODR, причём это было в легаси-коде пятнадцатилетней давности.
при тогдашнем компиляторе всё работало, а современный тихо и без шума генерил глючный код (имеет право, тут без претензий).
другой баг на этом же проекте отнял ещё больше времени.
воспроизводился он крайне странно: порой один раз из двухсот попыток, порой сериями по несколько раз подряд.
в итоге удалось его локализовать — корни ушли в системную библиотеку Xbox One.
"хакерскими" методами удалось его обойти, но майкрософт это не заапрувил (тут претензии уже есть).
баг в итоге остался, ушёл в продакшен, но я хотя бы могу с чистой совестью страдания пользователей не принимать на свой счёт.
Здравствуйте, 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 байта)?
Всю строку заполнять смысла нет. Тут главное именно в том, чтобы сделать поля невалидными.
Почитал ответы: почти все пишут, что не было такого, по 2 месяца ловят, но находят, и т.п. Стало интересно, раз все такие идеальные, то кто все те люди, которые поддерживают софт, у которого общеизвестные баги годами без движения висят?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, ути-пути, Вы писали:
УП>Почитал ответы: почти все пишут, что не было такого, по 2 месяца ловят, но находят, и т.п. Стало интересно, раз все такие идеальные, то кто все те люди, которые поддерживают софт, у которого общеизвестные баги годами без движения висят?
Здравствуйте, ути-пути, Вы писали:
УП>Почитал ответы: почти все пишут, что не было такого, по 2 месяца ловят, но находят, и т.п. Стало интересно, раз все такие идеальные, то кто все те люди, которые поддерживают софт, у которого общеизвестные баги годами без движения висят?
Это другое
И у меня есть баги которые годами лежат. Но если бы я таки слез с печи и взялся их чинить, то обязательно добил бы.
Здравствуйте, ути-пути, Вы писали:
УП>Здравствуйте, Khimik, Вы писали:
УП>Почитал ответы: почти все пишут, что не было такого, по 2 месяца ловят, но находят, и т.п. Стало интересно, раз все такие идеальные, то кто все те люди, которые поддерживают софт, у которого общеизвестные баги годами без движения висят?
У багов может быть низкий приоритет и за них просто никто не берётся — все чинят более важное. Или стоимость починки большая. Такое может висеть до конца жизни системы.
