Здравствуйте, 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-мь байт.
Внесение корректировок в код приложения, позволило решить данную проблему.

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

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