Неправильное использование атомов и трудноуловимая бага в VCL

[DirtyDog]

Вопрос автору (зная, что многие до сих пор пользуются 7 версией): какой версией Delphi Вы пользуетесь? Этот недочет точно актуален для последних версий? В любом случае большое спасибо за информацию и за решение.

[MrShoor]

Я проверял в Delphi 7, Delphi 2010, Delphi XE5. Я думаю что это есть во всех версиях делфи. Код VCL не менялся.

[mexanism]

после длительного аптайма системы и интенсивной отладки. Списки переставали обновляться, кнопки нажиматься, поля ввода терять фокус. И все было печально, и перезапуск IDE не помогал. Более того, после перезапуска IDE — она сама начинала так же глючить.

Сидишь работаешь и тут делфи начинает выбешивать своими глюками… ох как это знакомо.
Кстати stackoverflow.com/questions/514812/which-bug-in-the-delphi-ide-vcl-do-you-despise-the-most

[MrShoor]

Хех, почитал. :)
Это они еще в TLB редакторе дельфийском не работали. Вот где песня.

[alcr]

Меня настолько достали глюки tlb-редактора, что я сел и изучил idl. С тех пор не пользуюсб этим глюкаловом.

[kentaskis]

Спасибо, очень полезно. А нет ли ресурса, где собраны подобные баги Delphi с их решением? Было бы не лишним провести системе профилактическое лечение.

[pcmaniac]

delphikingdom.ru/stones/

[Pashkevich]

>> Можно убедится что атомы текут запустив любой VCL проект, и прибив его через диспетчер задач.
А если CTRL+F2 нажать, атомы тоже утекут?

[MrShoor]

Естественно утекут.

[serbod]

Пора переходить на FPC/Lazarus, там баги правятся в день обнаружения.

[MrShoor]

Там дебагер — плакать хочется. Пилю сейчас небольшой проектик на лазарусе.

[Demanoidos]

Delphi 10.2, 10.4 - ситуация не изменилась. Спасибо большое, начал использовать ваш код.

[Arioch]

Совершенно непонятно почему разработчики Delphi решили использовать атомы. Ведь обе эти функции прекрасно работают с указателями на строки. Достаточно передавать уникальную строку, которая сама по себе уже есть, ведь с ней инициализируется атом.

Вполне понятно почему. Вы же сами написали, что "использовать строку" - это то же самое, что использовать медленные атомы.

Минусы атомов останутся, но сверх того будет медленный линейный поиск по массиву строк, вместо того прямого чтения по индексу.

https://devblogs.microsoft.com/oldnewthing/20080502-00/?p=22483

https://devblogs.microsoft.com/oldnewthing/20080429-00/?p=22543

Другой вопрос, был ли на 16-битной Windows какой-то вариант лучше этого?.. Судя по всему особого выбора не было.

2008: These problems with properties were fixed a long time ago, but old-timers remain wary of adding named properties by string atom. It’s one of those superstitions.

Что такое 'long time ago' в 2008 вопрос открытый... Но вряд ли Windows 3.11 и Windows 95 в списке.

Вообще, если параноить, то наверное правильно было бы сделать так:

1. AllocateHWND

2. Добавить в это окно нужные 2-3 проперти

3. Получить их числовое значение через GlobalFindAtom или через пару GlobalAddAtom/GlobalDeleteAtom

4. Возможно, закрыть это окно в finalization. Или поверить, что в Windows действительно всё исправлено.

Но вопрос все тот же, а в каких версиях Windows была исправлена работа со свойствами окон? Фактически надо было бы в VCL вести две ветки кода, и правильно между ними переключаться. Исходя из какой-то недокументированной особенности некоторых версий Windows. Видимо, никто не захотел.

Это нетрудно прямо в памяти пропатчить, не пересобирая VCL, но очень ли надо?

то есть всего 16383

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

Строка собирается уникальной (из HInstance и ThreadID)

Не думаю, что есть гарантия уникальности этих чисел. ПОКА процесс/поток живы - да, уникально. Но когда они закрылись, вряд ли есть гарантия, что новый поток или процесс никогда не получат такой же номер, особенно на 16-битной системе.

Да ведь вы же сами написали:

после того как мы убедились что потока/процесса с таким ID нет ... процесс может появиться, с ровно таким же ID

P.S. Кстати, в Delphi есть и ещё одна утечка памяти при многократной загрузке/выгрузке DLL. Причем ЕМНИП никаких VCL не нужно. Как-то натыкался "теоретически", просматривая код Delphi 5. А сильно потом как-то раз нагуглил какого-то серверописателя, у которого процесс должен был месяцами работать, а вот DLL обработчиков запросов загружались/выгружались десятки раз в минуту. И процесс тупо помирал через несколько суток. Название этого Linked List of static arrays уже не помню. Может и исправили, но скорее всего опять же никому не надо.