Delphi: memoryleak in IdStack, but who uses IdStack?
Asked Answered
P

4

7

FAstMM reports a memoryleak from a TIdCriticalSection in IdStack.pas. I understand this is a intentional leak, that is documented in the code.

What I do not understand, is why IdStack is included in my project. How can I find out what unit pulls it in?

Is there a way of excluding this leak from the report, using the version of fastmm that comes with delphi 2007?

UPDATE: Is there a way of finding all the pas-files included in a build?

Pirate answered 13/8, 2009 at 9:10 Comment(0)
R
4

All Indy units have an 'Id' prefix, so check if you have any of those in your uses clauses.

Another way might be to place a breakpoint in TIdStack.create(). Eventually, the guilty one will show up in the call stack.

Renner answered 13/8, 2009 at 9:16 Comment(1)
I have tried breakpoints, but it never breaks. I looks like the initialization/finalization section is the only code that is run. I'm doing a massive grep now, to see if I can find anything.Pirate
L
8

The Delphi FastMM memory manager provides a method

function RegisterExpectedMemoryLeak(P: Pointer): boolean;

So, if you've found the unit and it turns out that you cannot remove it, you can use this method to supress a memory leak warning.

Ligamentous answered 13/8, 2009 at 12:28 Comment(0)
R
4

All Indy units have an 'Id' prefix, so check if you have any of those in your uses clauses.

Another way might be to place a breakpoint in TIdStack.create(). Eventually, the guilty one will show up in the call stack.

Renner answered 13/8, 2009 at 9:16 Comment(1)
I have tried breakpoints, but it never breaks. I looks like the initialization/finalization section is the only code that is run. I'm doing a massive grep now, to see if I can find anything.Pirate
I
4

There's a lot about this on the 'net, although it is scattered. It alo depends on whether you are using Indy 9 (with D7) or later. It's plauged me too. For Indy 9 I did the following in IdComponent.pas:

initialization
  GStackCriticalSection := TCriticalSection.Create;

  // BJF Starts
  //RegisterExpectedMemoryLeak(GStackCriticalSection);
  // BJF Ends

finalization
  // Dont Free. If shutdown is from another Init section, it can cause GPF when stack
  // tries to access it. App will kill it off anyways, so just let it leak

  // BJF has removed comments
  FreeAndNil(GStackCriticalSection);
end.

But note that you must put a path to the Indy source in the library path. I believe that Indy 10 is fixed in this respect. Brian

Infect answered 13/8, 2009 at 16:26 Comment(1)
Don't remove these comments. In a multi-threaded app, it can fail because of that. It is a global variable, and Windows will both release the memory and kernel handles (like critical sections) upon termination anyway. See this link and the articles it links to: blogs.msdn.com/b/oldnewthing/archive/2010/01/22/9951750.aspxBadtempered
P
2

Look at Uses in your .dpr Use cnPack (cnPack.org) and select 'Uses Cleaner' to remove units not referenced

Pru answered 13/8, 2009 at 11:14 Comment(2)
Another option to do this is Icarus, a free subset of Pascal Analyzer: peganza.com/#ICARUSCircumbendibus
wow. Have heard about cnPack, but never tried it out. That has to be changed! :-) Thanks.Pirate

© 2022 - 2024 — McMap. All rights reserved.