http://oss.sgi.com/bugzilla/show_bug.cgi?id=808
------- Additional Comments From hch@xxxxxxx 2008-12-27 06:26 CST -------
So looking at the differences of your trace to mine is that your glibc uses
getdents64 even without -D_FILE_OFFSET_BITS=64, while mine uses plain old
getdents, and it always does a llseek after the getdents which my glibc doesn't
do. My first getdents64 is exactly the same as yours (compiled with
-D_FILE_OFFSET_BITS=64) and the the writes from the printf in your program
follow, but it goes on until the file 168 entry, which it should for both our
cases given that getdents claims to have 170 entries in it's buffer which is 168
+ the "." and ".." entries:
getdents64(3, /* 170 entries */, 4096) = 4080
write(1, "file: . rc: Success\n"..., 20) = 20
write(1, "file: .. rc: Success\n"..., 21) = 21
...
write(1, "file: 167 rc: Success\n"..., 22) = 22
write(1, "file: 168 rc: Success\n"..., 22) = 22
Your trace then starts another getdents call:
getdents64(3, /* 1 entries */, 4096) = 24
which mine doesn't do, and which doesn't return an error either but what looks
like a single normal dirent structure.
Very strange things going on here, I'll see if I can find something fishy in the
glibc sources.
You don't happen to have a 2.6.27.<something> kernel still around and could
attach a strace from that one?
--
Configure bugmail: http://oss.sgi.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|