Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 6 of 6 total
Thread Help with a memory leak
Fri, Jul 20 2007 12:50 PMPermanent Link

Jon Lloyd Duerdoth
I've have had the following memory leak for some time and
just can't track it down

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
An unexpected memory leak has occurred.
The unexpected small block leaks are:

1 - 12 bytes: TIdThreadSafeInteger x 1
21 - 28 bytes: TIdCriticalSection x 2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I've even stripped the project file down to:

 ReportMemoryLeaksOnShutdown := DebugHook <> 0;
   Application.Initialize;
   Application.Run;

The project terminates immediately (of course) but
I still have the memory leak.

Any suggestions would be appreciated.

Jon
Fri, Jul 20 2007 1:42 PMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Jon


Just in case you hadn't guessed then going by the names its something to do with Indy, and unless Indy has improved a lot tracking stuff down in there is a nightmare.

Having said that I'm having my own nightmare tracking down a TStringList leak, and can't get FastMM's diagnostic report to be generated.

Roy Lambert
Fri, Jul 20 2007 2:01 PMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Jon


Googling for help in finding my leak I came across

http://groups.google.com/group/borland.public.delphi.language.basm/browse_thread/thread/4810f81f8e8a8d1e/05d13169e9337011?lnk=st&q=(fastmm+and+debugmode)+group%3Aborland.public.delphi.*&rnum=4#05d13169e9337011

Roy Lambert
Fri, Jul 20 2007 9:36 PMPermanent Link

Lance Rasmussen

Jazzie Software

Avatar

Team Elevate Team Elevate

I get that as well.

It's coming from Indy.

Lance


"Jon Lloyd Duerdoth" <jld@welshdragoncomputing.ca> wrote in message
news:AFB747FD-F931-4B1D-8F87-66CBFAAA454F@news.elevatesoft.com...
> I've have had the following memory leak for some time and
> just can't track it down
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> An unexpected memory leak has occurred.
> The unexpected small block leaks are:
>
> 1 - 12 bytes: TIdThreadSafeInteger x 1
> 21 - 28 bytes: TIdCriticalSection x 2
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I've even stripped the project file down to:
>
>  ReportMemoryLeaksOnShutdown := DebugHook <> 0;
>    Application.Initialize;
>    Application.Run;
>
> The project terminates immediately (of course) but
> I still have the memory leak.
>
> Any suggestions would be appreciated.
>
> Jon
Sat, Jul 21 2007 4:15 AMPermanent Link

Eryk Bottomley
Jon,

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> An unexpected memory leak has occurred.
> The unexpected small block leaks are:
>
> 1 - 12 bytes: TIdThreadSafeInteger x 1
> 21 - 28 bytes: TIdCriticalSection x 2
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I've even stripped the project file down to:
>
>  ReportMemoryLeaksOnShutdown := DebugHook <> 0;
>    Application.Initialize;
>    Application.Run;


They are resources being allocated in the initialization section of one
of the Indy units and then either not being freed in the finalization
section or else FastMM can't "see" them being freed. In either case it
is harmless. If the entire process address space is being trashed anyway
then whether these resources are explicitly freed or not is neither here
nor there. Initialization sections are only called once when a unit
first loads so the leak cannot accumulate (DLLs aside, which is not the
case here).

Eryk
Sat, Jul 21 2007 2:41 PMPermanent Link

Jon Lloyd Duerdoth
Thanks everyone for the comments... nice to know
I'm not alone!

Jon

Eryk Bottomley wrote:
> Jon,
>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> An unexpected memory leak has occurred.
>> The unexpected small block leaks are:
>>
>> 1 - 12 bytes: TIdThreadSafeInteger x 1
>> 21 - 28 bytes: TIdCriticalSection x 2
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> I've even stripped the project file down to:
>>
>>  ReportMemoryLeaksOnShutdown := DebugHook <> 0;
>>    Application.Initialize;
>>    Application.Run;
>
>
> They are resources being allocated in the initialization section of one
> of the Indy units and then either not being freed in the finalization
> section or else FastMM can't "see" them being freed. In either case it
> is harmless. If the entire process address space is being trashed anyway
> then whether these resources are explicitly freed or not is neither here
> nor there. Initialization sections are only called once when a unit
> first loads so the leak cannot accumulate (DLLs aside, which is not the
> case here).
>
> Eryk
Image