False leak reported on FindFirst/Findclose inside a Threa?

[alogrep 0]

HI.

I can't understand why Madexcept shows a leak on FIndFirst/FindClose.

THis is what I have :

type
  SendThread = class(TThread)
  private
   CriticalSection: TCriticalSection;
   fmods:modslist;
   tablename: string;
   savedir: string;
   dbase: string;
   uniq: integer;
  public
    Constructor Create(afmods:modslist; atablename: string;uniquenumber: int64;asavedir,adbase: string);
    Destructor Destroy; override;
    procedure Execute; override;
    procedure Fields2sTREAM(fmods:modslist; tablename: string; dbase: Tnxdatabase);
  end;

CriticalSection is created in the Create constructor and free-d in Destroy.

In the Execute, I have this.

 CriticalSection.Acquire;
 try
   s:=savedir+'\*'+lowercase(dm2.uniquenumber.tablename)+'.db';
   if findfirst(s,faAnyFile,sr)=0 then  begin
     Deletefile(savedir+'\'+sr.name);
     FindClose(SR);
   end;
   s:=Format('%.*d',[13, uniq]);
   s:= savedir+'\'+s+'$pos-'+lowercase(dm2.uniquenumber.tablename)+'.db';
   sStream.savetofile(s);
 finally
   CriticalSection.Release;
 end;

Any clue anybody?

[corneliusdavid 220]

if "FindFirst() = 0" returns false, then FindClose() is never called.

 

From the documentation: "FindFirst allocates resources (memory) that must be released by calling FindClose"

[Anders Melander 1815]

6 minutes ago, corneliusdavid said:

if "FindFirst() = 0" returns false, then FindClose() is never called.

From the documentation: "FindFirst allocates resources (memory) that must be released by calling FindClose"

The documentation is partly wrong.

 

FindFirst wraps the FindFirstFile Windows API function which documentation more correctly state:

Quote

If the function succeeds, the return value is a search handle used in a subsequent call to FindNextFile or FindClose, and the lpFindFileData parameter contains information about the first file or directory found.

If the function fails or fails to locate files from the search string in the lpFileName parameter, the return value is INVALID_HANDLE_VALUE and the contents of lpFindFileData are indeterminate.

So on failure there is nothing to free with FindClose; If you look at the source you will see that FindClose does nothing if the result of FindFirstFile was

INVALID_HANDLE_VALUE.

 

[corneliusdavid 220]

2 minutes ago, Anders Melander said:

So on failure there is nothing to free with FindClose;

Ah! Then ignore my post. Thanks for pointing that out.

[Brian Evans 109]

Would help if the poster mentioned what the leak was. 

[alogrep 0]

Thanks. But I DO use FindClose() in my code. The "leak report"  says nothing more than what is whown in the attached image.

[alogrep 0]

Sorry, there was another FindFirst() very close to the first one  without FindClose().

[corneliusdavid 220]

2 minutes ago, alogrep said:

But I DO use FindClose()

Right, but only if FindFirst returns true; if it's false, that block of code, including FindClose, is skipped. However, as Anders pointed out, if FindFirst fails, it doesn't allocate memory and thus does not need to call FindClose.

 

It's possible that MadExcept is thinking that there could be a memory leak when there isn't actually one.

[corneliusdavid 220]

1 minute ago, alogrep said:

Sorry, there was another FindFirst() very close to the first one  without FindClose().

Oh, so the error was in code that we did not see! LOL! That makes it difficult for us to debug! 

[alogrep 0]

Well I did say "I'm sorry". Of course if I had "seen" that other part of the code, probably I would not have asked for help.

[Anders Melander 1815]

2 hours ago, alogrep said:

there was another FindFirst() very close to the first one  without FindClose().

The next time you get a leak report from madExcept, double-click in the lower pane on the line that caused the leak and it will open up the unit in Delphi and place the cursor right where the allocation occurs: