Hi, I ported a Delphi service to linux using FPC. The app uses FindFirst, FindNext and FindClose the same way Delphi Help shows:

if FindFirst(Edit1.Text, FileAttrs, sr) = 0 then
begin
  repeat
    ...
    ...
  until FindNext(sr)  0;
  FindClose(sr);
end;

Apparently my program gets stuck after a couple (several, in fact) of calls to the function that includes this code.

By reading the FPC.RTL documentation, I found it says that FindClose must be used outside the if, as follows:

if FindFirst(Edit1.Text, FileAttrs, sr) = 0 then
begin
  repeat
    ...
    ...
  until FindNext(sr)  0;
end;
FindClose(sr);

Can be this the cause of the problem in my application?.

Thanks in advance.

Leonardo M. Ramé
http://leonardorame.blogspot.com

Yes.

Jonas

Huh ? Since when is this requirement ?

If it is correct, 100% of my FindFirst/FindClose code must be rewritten !

Michael.

You are not alone Michael, I also have to rewrite all of my FindFirst...FindClose calls :).

By reading the documentation a little more, I found that the unit OldLinux includes the Glob() function to search for files in Linux. This function returns a pointer that must be explicitly disposed by the GlobFree function, it doesn't matter if files where found or not.

I can't confirm this, but maybe FindFirst in linux is a wrapper to Glob, and that's why FindClose (in Linux) must be called outside the if.

Leonardo M. Ramé
http://leonardorame.blogspot.com

Since as long as I can remember. It at least predates the switch to svn (revision 1 of both rtl/unix/dos.pp and of rtl/unix/sysutils.pp requires it).

Jonas

As far as I know, the FindClose is only needed when FindFirst returned zero. At least, that's what you can deduce from MSDN, and this is how I programmed it since ages.

Michael.

I must agree with Michael.

In my experience, it doesn't matter where the findclose() is placed, as long as it's called within the scope of the findfirst(), findnext(). If findclose() is not called, all that happens is that the OS will use up file handles, which are finite in quantity on any given system.

If you're using Delphi or FPC in MS Windows, fire up Task Manager, check the "Handles" column within the "processes" tab in task manager to see if handles are being "lost" from within your app.

BTW, Task manager is a simple debugging "tool" that helps identify how your app is doing with regards to a range of resources, memory, etc. I also use KDE System Guard when coding for Linux.

:=Nino
//*****************************************************************************************************

Is that correct:
http://www.delphifaq.com/faq/delphi/windows_file_system/f419.shtml ?

If yes, then you need IFDEFs to distinguish between Linux and Windows. ;-(

Jürgen Hestermann

In our previous episode, Jonas Maebe said:

The current situation is probably simply the old "linux" unit routines folded into sysutils. The fact that it is documented that way probably makes it more than likely it was no mistake.

Michael Van Canneyt wrote

As far as I know, the FindClose is only needed when FindFirst returned zero.

That has never been true on FPC/unix, as far as I can see.

Jonas

Given that I documented it, I'd rather say that I was sloppy in the formulation. I've always assumed that the findclose was only needed in case of a _succesful_ findfirst, i.e. one that returns 0. And I've seen a lot of code that assumes the same (admittedly, it was Win32 code).

Once more, if this is so, there is a lot of code that needs to be checked in FPC. It might be easier to "fix" findfirst so that in case of an error (nonzero return value), the searchrec record is cleared, and the findclose() call is redundant.

I checked the windows code, and FindClose explicitly checks that the searchrec record contains a valid handle (i.e. NOT INVALID_HANDLE_VALUE), so all platforms would behave the same.

Opinions ? If no-one objects, I'll implement the 'fix', it's only 2 lines of code.

Michael.

This sounds good, just also check what happens if FindClose receives an invalid handle.

Leonardo M. Ramé
http://leonardorame.blogspot.com

Leonardo M. Ramé wrote

This sounds good, just also check what happens if FindClose receives an invalid handle.

That was the second line in my line count estimate ;-)

Michael.

There will be no need for an ifdef. All code will continue to work as-is. Only memory leaks that now may exist will be solved.

Michael.

In our previous episode, Michael Van Canneyt said:

Opinions ? If no-one objects, I'll implement the 'fix', it's only 2 lines of code.

No fundamental objections, but maybe wait till just before a release to avoid packages that work with both 2.2.4 and 2.3.1 having to ifdef till the next release?

It's fine by me.

Jonas

No problem here either, just make sure that you check whether SysUtils.FindFirst and Dos.FindFirst are consistent in this context (i.e. probably more than two lines of code are necessary even if disregarding any other platforms out there apart from Unix ;-) ).

Tomas