Утечка памяти в службе Windows (CodeGear C ++ XE5) с использованием Indy TIdTCPServer

У меня есть CodeGear C ++ Builder XE5. Сервер создан с помощью TIdTCPServer, который прекрасно работает.
Однако используемая службой память растет. Мне наконец удалось включить полную версию диспетчера памяти FastMM4, и, поиграв с опциями, я нашел подтверждение утечки памяти:

13 - 20 bytes: TIdThreadSafeInteger x 1
21 - 36 bytes: TIdCriticalSection x 2, Unknown x 1
53 - 68 bytes: UnicodeString x 1
85 - 100 bytes: Unknown x 21
149 - 164 bytes: Unknown x 21
181 - 212 bytes: Unknown x 2

Очевидно, x1 и x2 меня не касаются, однако утечки x21 плохие, так как это очень популярный сервис — каждое соединение отбирает 100 и 164 байта:

более подробная информация гласит:

A memory block has been leaked. The size is: 100

This block was allocated by thread 0xD98, and the stack trace (return addresses) at the time was:
8D4743 [Unknown function at @@Zip_int@Finalize]
8D461D [Unknown function at @@Zip_int@Finalize]
8E0F94 [Unknown function at @@Zip_int@Finalize]
8E0F59 [Unknown function at @@Zip_int@Finalize]
8DFADA [Unknown function at @@Zip_int@Finalize]
8DE722 [Unknown function at @@Zip_int@Finalize]
8BF045 [Unknown function at @@Searchfilelist@Finalize]
8C4C90 [Unknown function at @@Searchfilelist@Finalize]
8D6638 [Unknown function at @@Zip_int@Finalize]
775D1C77 [Unknown function at RtlNtStatusToDosErrorNoTeb]
452A45 [@Fastmm4@DebugGetMem$qqri]

The block is currently used for an object of class: Unknown

A memory block has been leaked. The size is: 164

This block was allocated by thread 0x5394, and the stack trace (return addresses) at the time was:
8D4743 [Unknown function at @@Zip_int@Finalize]
8D461D [Unknown function at @@Zip_int@Finalize]
8E0FD9 [Unknown function at @@Zip_int@Finalize]
8E0F59 [Unknown function at @@Zip_int@Finalize]
8DFADA [Unknown function at @@Zip_int@Finalize]
8DE722 [Unknown function at @@Zip_int@Finalize]
8BF045 [Unknown function at @@Searchfilelist@Finalize]
8C4C90 [Unknown function at @@Searchfilelist@Finalize]
8D6638 [Unknown function at @@Zip_int@Finalize]
775D1C77 [Unknown function at RtlNtStatusToDosErrorNoTeb]
452A45 [@Fastmm4@DebugGetMem$qqri]

The block is currently used for an object of class: Unknown

The allocation number is: 125893

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

0

Решение

Первые две утечки — TIdThreadSafeInteger а также TIdCriticalSection — хорошо известные утечки в Indy, которые происходят только при завершении работы приложения, поскольку они являются глобальными объектами, намеренно не освобожденными. Я удивлен, увидев их в отчете об утечке, поскольку Indy регистрирует их в FastMM как известные утечки.

Другие не являются утечками Indy. Ваш код должен выделять то, что вы не освобождаете. UnicodeString Утечка может быть указанием на это, так как наиболее распространенный способ утечки String — это если он является членом экземпляра класса, который не освобожден. Если утечки пропорциональны количеству соединений, которые получает ваш сервер, то вы, вероятно, что-то выделяете и сохраняете в TIdContextнапример, в OnConnect событие, а не освобождение позже, например, в OnDisconnect событие. Но вы не показали свой код.

Что я нахожу странным, так это то, что утечки, по-видимому, распределяются во время финализации модуля, а не во время обычного запуска приложения, но почему их так много Finalize звонит вместе, я не знаю. Если информация трассировки стека приложения не верна. FastMM не может сообщить более значимую информацию, потому что эти модули, вероятно, не были скомпилированы с включенной отладочной информацией. У вас есть хотя бы файл .MAP, сгенерированный компилятором для вашего приложения? Это помогает FastMM распознавать имена функций из адресов памяти.

1

Другие решения


По вопросам рекламы ammmcru@yandex.ru
Adblock
detector