Доброго времени суток, уважаемые!

Второй день бьюсь над проблемой, которую мне выдает FastMM. Немного предистории:
Конфигурация: Delphi 2010, FastMM 4.97, MadExcept 3/0m.
Проблемное приложение: многопоточный сервер, все потоки - через стандартный TThread. Если завершить его (сервер, в смысле) при наличии активных подключений, то FastMM начинает ругаться (файл с руганью - во вложении).
При этом:
- все объекты нормально уничтожаются, каждый - в своем потоке (т.е. нет такого, что создан в одном, а уничтожен в другом потоке)
- финализация всех модулей (где есть секция финализации) проходит без замечаний. В секциях финализации освобождаются общие экземпляры классов, но на момент уничтожения они пусты.

После завершения финализации всего и вся - FastMM выдает вот это.

Не могу понять, в чем дело - я же не обращаюсь к уже освобожденным объектам, иначе FastMM отреагировала бы сразу же.

Есть какие-нибудь мысли?

Присоединённый файл ( Кол-во скачиваний: 5 )
 LogisticServer_MemoryManager_EventLog.txt 3,73 Kb

А если отключить ругань со стороны FastMM и madExcept, и отключить всё игнорирование исключительных ситуаций в самой делфи не станет ли проще локализовать проблему?

Сейчас мне так кажется, по стеку в том что в каком-то потоке вы что-то создали, а оно несколько не уничтожилось, или уничтожилось что-то одно, а какой-то объект остаётся существовать...

У меня так было при включённой опции FreeOnTerminate, получались забавные ошибки и непонятные. Я отключил её и поток руками убиваю, так лучше при конкретно моей реализации.

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

Сейчас вот убрал вообще весь код из initialization/finalization. Не помогло.


Не пользуюсь. Из-за нее действительно могут быть проблемы, гораздо лучше самому контролировать. Да и в этом случае выскочило бы AV (ну, это мечты, конечно ).

Сейчас пытаюсь понять, чем же может отличаться завершение программы без активных TCP подключений от имеющей таковые...


Это как и где отключается? Не включал ничего в этом духе...

Обычно если галочка есть, то при исключении, которое обрабатывается ничего не происходит(ну или происходит), а вот без обработчика вылетает сообщение где много букав, а толку мало.
Оно включается если при вылете Except'а под отладчиком, в диалоге поставить галочку "ignore exception"
Отключается очень просто Tools->Options->Debugger Options->Language Exceptions, и там снять все галочки.


Тем что возможно обработчики каким-то чудом ещё работают...(бред больного человека, но всё же   )

P.S. вроде в 2010 там также было всё расположено

Не, я такими вещами не балуюсь  Как стояло по умолчанию игнорировать только Indy, так и стоит. Полностью солидарен в этом с Delphi - я тоже игнорирую индейцев.

В общем, разобрался и нашел. Как обычно - совсем не там, куда указывалось FastMM. Хотя, надо признать - причина лежала рядом, совсем рядом.

Порядок разбора был следующим:
0. Ошибка стабильная, повторяется 1:1 при одинаковых действиях с программой (огромная удача, если честно).
1. Проверил, что при нормальном завершении TCP соединения ошибок не возникает, а если завершение соединения вызывано завершением работы сервера (прошу прощения за тавтологию) - то ошибка имеет место быть.
2. Промежуточный вывод - проблема действительно в коде обработчиков закрытия сокетов и "окололежащих с ними".
3. Просмотр всего кода, относящегося к завершению соединения с обдумыванием "а как оно действует при завершении программы"
4. Нашел узкий участок - относительно сложная связь экземпляров классов через события. Оказалось, что из-за этой связи может быть вызван метод принудительного завершения соединения, что само собой лишнее - соединение и так уже закрывается (программа-то завершается).
5. Ликвидировал двойной вызов (просто обnilил событие в деструкторе)
6. Наслаждаюсь. Правда, недолго - теперь проблема (уже другого плана) на клиенте