I think this is a critical bug. I've also got lots of troubles with the Linux compiler lately: it often gets in an endless loop. When I strace it, you can see it keeps fstat'ing "." and ".." in succession, without ever going to the next item. So it's probably related to this bug.

That's sounds like this bug, yes. I had that problem also. But I can imagine that patching so close before a release can give some problems...

A good test is to run the following program from /usr/lib (or another LARGE directory.) Maybe Peter could try that once with a new kernel?

---
program test_readdir;
var str : string;
begin
  getdir(0,str);
  writeln(str);
end.
---

Joost van der Sluis.

Getdir is indeed a function that would provoke the ../ ./ alternate searching behaviour in strace that Jonas described, if something was wrong with readdir.

Marco van de Voort wrote

Getdir is indeed a function that would provoke the ../ ./ alternate searching behaviour in strace that Jonas described, if something was wrong with readdir.

Here's part of the strace of the compiler. It mainly occurs on nfs mounts:

stat("fpc.cfg", 0xbff8d3e8) = -1 ENOENT (No such file or directory)
stat("/user/jmaebe/.fpc.cfg", 0xbff8d2d4) = -1 ENOENT (No such file or directory)
stat("/etc/fpc.cfg", 0xbff8d2d4) = -1 ENOENT (No such file or directory)
stat("ppc386.cfg", 0xbff8d3e8) = -1 ENOENT (No such file or directory)
stat("/user/jmaebe/.ppc386.cfg", {st_mode=S_IFREG|0644, st_size=155, ...}) = 0
open("/user/jmaebe/.ppc386.cfg", O_RDONLY) = 3
read(3, "\n#ifdef i386\n-OG2p3u\n#endif\n#ifd"..., 256) = 155 stat("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat(".", {st_mode=S_IFDIR|0755, st_size=3298, ...}) = 0 stat("..", {st_mode=S_IFDIR|0755, st_size=2924, ...}) = 0 open("..", O_RDONLY) = 4
readdir(4, {d_ino=2013630, d_name=""}) = 1
stat("../.", {st_mode=S_IFDIR|0755, st_size=2924, ...}) = 0 readdir(4, {d_ino=2013630, d_name=""}) = 1
stat("../.", {st_mode=S_IFDIR|0755, st_size=2924, ...}) = 0 readdir(4, {d_ino=2013630, d_name=""}) = 1
stat("../.", {st_mode=S_IFDIR|0755, st_size=2924, ...}) = 0 readdir(4, {d_ino=2013630, d_name=""}) = 1
stat("../.", {st_mode=S_IFDIR|0755, st_size=2924, ...}) = 0 readdir(4, {d_ino=2013630, d_name=""}) = 1

[endless loop]

It's not due to a recently introduced compiler/rtl change, because I still have a copy of 1.0.7 here and it behaves the same.

Jonas

Strange. I've always compiled Lazarus on a NFS mount and I've never run into this. I've tried the example of Joost on different filesystems (ext3, nfs, smbfs), but always got the right output.

[snip]

[endless loop] It's not due to a recently introduced compiler/rtl change, because I still have a copy of 1.0.7 here and it behaves the same.

both a 1.9.3 (a few weeks old) and a 1.0.10 compiler worked fine

Marc

I'm running under Fedora Core 1 with the latest patches applied (that's kernel 2.4.22-1.2115.nptl), maybe that has something to do with it. Anyway, the is completely reproducible over different machines. I can still cycle perfectly in /tmp, but as soon as I try to compile something in my nfs-mounted home directory, I get this hang (only with FPC, gcc can perfectly compile things in my home directory).

Jonas

Hmm, I know from FreeBSD code that the libc code has a lot of checks extra over the minimally required functionality.

A workaround btw is making your FPC with FPC_USE_LIBC.

Strange. I've always compiled Lazarus on a NFS mount and I've never run into this. I've tried the example of Joost on different filesystems (ext3, nfs, smbfs), but always got the right output.

Which kernel do you use?

Joost.

2.4.20-8smp (RH9) and 2.4.18-3smp (RH7.3 +)

Marc

Those are 'too old' for this problem to occur. It only happens at newer kernels, at least that's what I think. (I'm using the FC2-test1 kernels)

Joost.