Package: findutils; Maintainer for findutils is Andreas Metzler <ametzler@debian.org>; Source for findutils is src:findutils (PTS, buildd, popcon).
Reported by: Andrew Reid <Andrew.Reid@nist.gov>
Date: Thu, 1 Apr 2004 20:18:43 UTC
Severity: normal
Found in version 4.1.20-3
Done: Andreas Metzler <ametzler@downhill.at.eu.org>
Bug is archived. No further changes may be made.
Forwarded to bug-findutils@gnu.org
View this report as an mbox folder, status mbox, maintainer mbox
Report forwarded to debian-bugs-dist@lists.debian.org, Andreas Metzler <ametzler@debian.org>:
Bug#241538; Package findutils.
(full text, mbox, link).
Acknowledgement sent to Andrew Reid <Andrew.Reid@nist.gov>:
New Bug report received and forwarded. Copy sent to Andreas Metzler <ametzler@debian.org>.
(full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
Package: findutils Version: 4.1.20-3 I am having a rather strange difficulty with the "find" command. For many paths on my system, including all paths in my account, I get: > # find <path> -print > find: <path>: Value too large for defined data type The failure occurs in some directories but not others, as described below. The set-up of the machine is such that user home directories can be accessed by multiple routes from the start of the file system. I am not certain that this is relevant, but describe it here for completeness. Users' actual home directories are divided into several numbered "home" directories from the root, like this: /u/home<n>/<user>/ All user home directories are accessible via symlinks from /u/users/<user> -> /u/home<n>/<user> There is also a symlink at the root of the filesystem, /users -> /u/users The client is an x86 machine. The filesystems are remotely mounted "xfs" file systems, mounted via NFS from an SGI file server. Each home<n> subdirectory is separately mounted on the client by way of an automounter. Most of these reside on separate disks on the server, except for home1 and home2, which share a physical disk on the server. The problem occurs for some of the /u/home<n>/ directories, but not others. All of these directories are exported identically (to each other) from the file server, and imported identically by the client. There are hardware differences between the mounted disks, which correlate with the "find" problem -- home directories which occupy 48GB disks and use more than 28GB of them seem to have this problem. The problem is also common to all of the largest filesystems. On a Debian "stable" client, importing the same file systems from the same file server, running the same kernel, but using "find" from version 4.1.7-2 of findutils, the problem does not occur. On all systems, these calls work. # find /u -maxdepth 1 # find /u/users -maxdepth 1 On the problem system in the problem directories, these calls: # find /u/home<n> -maxdepth 1 fail with the "Value too large" error -- this path argument is the direct path to the home directory. Although the filesystem and automounter configuration on these machines is not trivial, it is nevertheless identical between "stable" and "testing" machines, and the "find" bug occurs only on the "testing" machines. There is circumstantial evidence that the problem involves large xfs filesystems. -- A. -- Dr. Andrew C. E. Reid, Guest Researcher Center for Theoretical and Computational Materials Science National Institute of Standards and Technology, Mail Stop 8500 Gaithersburg MD 20899 USA andrew.reid@nist.gov
Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Metzler <ametzler@debian.org>:
Bug#241538; Package findutils.
(full text, mbox, link).
Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Andreas Metzler <ametzler@debian.org>.
(full text, mbox, link).
Message #10 received at 241538@bugs.debian.org (full text, mbox, reply):
On 2004-04-01 Andrew Reid <Andrew.Reid@nist.gov> wrote:
> Package: findutils
> Version: 4.1.20-3
> I am having a rather strange difficulty with the "find" command.
> For many paths on my system, including all paths in my
> account, I get:
> > # find <path> -print
> > find: <path>: Value too large for defined data type
[...]
Could you use ltrace to get more detailed information?
cu andreas
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
Noted your statement that Bug has been forwarded to bug-findutils@gnu.org.
Request was from Andreas Metzler <ametzler@logic.univie.ac.at>
to control@bugs.debian.org.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Metzler <ametzler@debian.org>:
Bug#241538; Package findutils.
(full text, mbox, link).
Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Andreas Metzler <ametzler@debian.org>.
(full text, mbox, link).
Message #17 received at 241538@bugs.debian.org (full text, mbox, reply):
On 2004-04-01 Andrew Reid <Andrew.Reid@nist.gov> wrote:
> Package: findutils
> Version: 4.1.20-3
> I am having a rather strange difficulty with the "find" command.
> For many paths on my system, including all paths in my
> account, I get:
> > # find <path> -print
> > find: <path>: Value too large for defined data type
[...]
While browsing upstream's bugtracker where I had forwarded the bug to
I found this in
http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=8455
-----------------------
The likely difference between the two versions of find is that they
use a different version of gnulib, and the updated version is now
sensitive to this problem. Alternatively, maybe it's a glibc
difference. Certainly the differences between the find application
code is minimal.
Looking at the ltrace output, it looks like readdir() is failing. The
likely bit of affected code is gnulib's savedir.c. That certainly
should faiil if readdir() fails.
I suspect that somewhere in there is a filename whose base name is
more than 256 characters. To find out, please try this (on either the
client or the server):
ls -R1 | awk '(length > 200) {print length, $0;}' | sort -n | tail
Try picking the last filename from the above and invoking find
directly on it. The idea here is to pin things down to one path name
that successfully reproduces the error.
Lastly, the output of "ltrace" isn't very helpful about the data
that's returned from the system calls. What do you get if you use
"strace"? What about "ltrace -S"?
-----------------------
cu andreas
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Metzler <ametzler@debian.org>:
Bug#241538; Package findutils.
(full text, mbox, link).
Acknowledgement sent to James Youngman <noreply@savannah.gnu.org>:
Extra info received and forwarded to list. Copy sent to Andreas Metzler <ametzler@debian.org>.
(full text, mbox, link).
Message #22 received at 241538@bugs.debian.org (full text, mbox, reply):
This mail is an automated notification from the bugs tracker
of the project: findutils.
/**************************************************************************/
[bugs #8455] Latest Modifications:
Changes by:
James Youngman <jay@gnu.org>
'Date:
Mon 11/22/04 at 00:45 (GMT)
------------------ Additional Follow-up Comments ----------------------------
I've created a local XFS filesystem with a couple of million files in it (one directory has over 900,000 entries). find searches it in about 15 seconds without failing. I'm not using NFS though.
/**************************************************************************/
[bugs #8455] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8455>
Project: findutils
Submitted by: Andreas Metzler
On: Mon 04/05/04 at 15:29
Category: find
Severity: 5 - Average
Item Group: None
Resolution: None
Privacy: Public
Assigned to: None
Originator Name:
Originator Email:
Status: Open
Release: None
Fixed Release: None
Summary: anomaly on large xfs filesystems
Original Submission: This is a copy of <http://bugs.debian.org/241538>.
Andrew Reid writes:
--------------------------
Version: 4.1.20-3
I am having a rather strange difficulty with the "find" command.
For many paths on my system, including all paths in my
account, I get:
> # find <path> -print
> find: <path>: Value too large for defined data type
The failure occurs in some directories but not others, as described
below.
The set-up of the machine is such that user home directories can be
accessed by multiple routes from the start of the file system. I am
not certain that this is relevant, but describe it here for
completeness.
Users' actual home directories are divided into several numbered
"home" directories from the root, like this: /u/home<n>/<user>/
All user home directories are accessible via symlinks from
/u/users/<user> -> /u/home<n>/<user>
There is also a symlink at the root of the filesystem,
/users -> /u/users
The client is an x86 machine. The filesystems are remotely mounted
"xfs" file systems, mounted via NFS from an SGI file server. Each
home<n> subdirectory is separately mounted on the client by way of an
automounter. Most of these reside on separate disks on the server,
except for home1 and home2, which share a physical disk on the server.
The problem occurs for some of the /u/home<n>/ directories, but not
others.
All of these directories are exported identically (to each other) from
the file server, and imported identically by the client. There are
hardware differences between the mounted disks, which correlate with
the "find" problem -- home directories which occupy 48GB disks and use
more than 28GB of them seem to have this problem. The problem is also
common to all of the largest filesystems.
On a Debian "stable" client, importing the same file systems from the
same file server, running the same kernel, but using "find" from
version 4.1.7-2 of findutils, the problem does not occur.
On all systems, these calls work.
# find /u -maxdepth 1
# find /u/users -maxdepth 1
On the problem system in the problem directories, these calls:
# find /u/home<n> -maxdepth 1
fail with the "Value too large" error -- this path argument
is the direct path to the home directory.
Although the filesystem and automounter configuration on these
machines is not trivial, it is nevertheless identical between "stable"
and "testing" machines, and the "find" bug occurs only on the
"testing" machines. There is circumstantial evidence that the problem
involves large xfs filesystems.
--------------------------
He later provided me with the ltrace I am attaching.
thanks, cu andreas
Follow-up Comments
------------------
-------------------------------------------------------
Date: Mon 11/22/04 at 00:45 By: James Youngman <jay>
I've created a local XFS filesystem with a couple of million files in it (one directory has over 900,000 entries). find searches it in about 15 seconds without failing. I'm not using NFS though.
-------------------------------------------------------
Date: Sat 10/02/04 at 10:48 By: James Youngman <jay>
OK, having looked at the trace output, I still suspect that it is savedir() which is failing. I have a small number of questions.
1. If you use "tar" to copy the directory tree to a local filesystem, can you reproduce the problem? Don't forgert to use the "p" option when unpacking.
The other checks involve getting hold of a copy of the source. If you're not confident with compiling source code, don't worry about it. Otherwise, I have a couple of other suggested tests:
a) Change error() [in file error.c] so that it calls abort(). Then use GDB to get a stack backtrace from the coredump. Send me a copy of the stack backtrace. For the lower levels of the backtrace (say 3 as a guideline) show me which line that corresponds to (the will avoid problems caused by us looking at different versions of the code).
b) Use GDB to single-step through savedir() to figure out why it fails - if indeed (b) shows that it has failed.
Sorry to make you do all the work, but I can't reproduce the problem here.
-------------------------------------------------------
Date: Mon 08/30/04 at 15:54 By: 0 <None>
On Mon, Aug 09, 2004 at 01:01:12PM +0200, Andreas Metzler wrote:
> On 2004-04-01 Andrew Reid <Andrew.Reid@nist.gov> wrote:
> > Package: findutils
> > Version: 4.1.20-3
>
> > I am having a rather strange difficulty with the "find" command.
>
> > For many paths on my system, including all paths in my
> > account, I get:
>
> > > # find <path> -print
> > > find: <path>: Value too large for defined data type
> [...]
>
Thanks for the reply and sorry about my delay in replying -- partially
it's vacation season, and partially I've just been doing other stuff.
> While browsing upstream's bugtracker where I had forwarded the bug to
> I found this in
> http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=8455
>
> -----------------------
> The likely difference between the two versions of find is that they
> use a different version of gnulib, and the updated version is now
> sensitive to this problem. Alternatively, maybe it's a glibc
> difference. Certainly the differences between the find application
> code is minimal.
>
> Looking at the ltrace output, it looks like readdir() is failing. The
> likely bit of affected code is gnulib's savedir.c. That certainly
> should faiil if readdir() fails.
>
> I suspect that somewhere in there is a filename whose base name is
> more than 256 characters. To find out, please try this (on either the
> client or the server):
>
> ls -R1 | awk '(length > 200) {print length, $0;}' | sort -n | tail
This suspicion is not confirmed, alas -- the awk returns nothing
with length > 200. To check that it worked at all, I ratcheted
down the number, and I start to get lots of stuff once it's
less than around 50. Nothing longer than 100. I made no attempt
to refine it beyond that.
> Try picking the last filename from the above and invoking find
> directly on it. The idea here is to pin things down to one path name
> that successfully reproduces the error.
I appreciate the need for diagnosing under controlled conditions,
so I've picked a directory to run it, which I will use for future
tests, if any...
> Lastly, the output of "ltrace" isn't very helpful about the data
> that's returned from the system calls. What do you get if you use
> "strace"? What about "ltrace -S"?
Here's another crack at it -- in case you're curious, this was
test code for what, exactly, Python does to its internal search
paths at start-up time.
Also, recall that the filesystem being examined is an SGI XFS
filesystem which is NFS mounted by the Debian Sarge linux box
which is actually running the "find" command.
The directory:
> poppins[reida]: ls -al
> total 24
> drwxr-xr-x 2 reida user 95 Feb 3 2004 ./
> drwxr-xr-x 22 reida user 4096 Aug 25 20:35 ../
> -rw-r--r-- 1 reida user 20 Feb 3 2004 stuff.py
> -rw-r--r-- 1 reida user 229 Feb 3 2004 stuff.pyc
> -rw-r--r-- 1 reida user 44 Feb 3 2004 stuff.py~
> -rwxr-xr-- 1 reida user 230 Feb 3 2004 test.py*
> -rw-r--r-- 1 reida user 95 Feb 3 2004 test.py~
Debian Woody, with strace output afterwards.
> jeeves[reida]: find . -name "*.py"
> ./test.py
> ./stuff.py
> jeeves[reida]: strace find . -name "*.py"
> execve("/usr/bin/find", ["find", ".", "-name", "*.py"], [/* 35 vars */]) = 0
> uname({sys="Linux", node="jeeves", ...}) = 0
> brk(0) = 0x8053d54
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib", {st_mode=S_IFDIR|0755, st_size=776, ...}) = 0
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=41861, ...}) = 0
> old_mmap(NULL, 41861, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
> close(3) = 0
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "177ELF111 3 3 1 30222"..., 1024) = 1024
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1153784, ...}) = 0
> old_mmap(NULL, 1166560, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001f000
> mprotect(0x40132000, 40160, PROT_NONE) = 0
> old_mmap(0x40132000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x113000) = 0x40132000
> old_mmap(0x40138000, 15584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40138000
> close(3) = 0
> munmap(0x40014000, 41861) = 0
> brk(0) = 0x8053d54
> brk(0x8053d7c) = 0x8053d7c
> brk(0x8054000) = 0x8054000
> time(NULL) = 1093877075
> open(".", O_RDONLY|O_LARGEFILE) = 3
> fchdir(3) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> chdir(".") = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> brk(0x8055000) = 0x8055000
> open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> fstat64(4, {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> brk(0x8058000) = 0x8058000
> getdents64(0x4, 0x8054148, 0x2000, 0) = 208
> getdents64(0x4, 0x8054148, 0x2000, 0) = 0
> close(4) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
> write(1, "./test.pyn", 10./test.py) = 10
> write(1, "./stuff.pyn", 11./stuff.py) = 11
> fchdir(3) = 0
> munmap(0x40014000, 4096) = 0
> _exit(0) = ?
... then Debian Sarge: Since this is the system with the problem,
I have included both strace and ltrace -S output -- they seem to not
quite be the same, so you may of course use whichever is most useful
to you.
> poppins[reida]: find . -name "*.py"
> find: .: Value too large for defined data type
> poppins[reida]: strace find . -name "*.py"
> execve("/usr/bin/find", ["find", ".", "-name", "*.py"], [/* 46 vars */]) = 0
> uname({sys="Linux", node="poppins", ...}) = 0
> brk(0) = 0x80545b4
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib", {st_mode=S_IFDIR|0755, st_size=776, ...}) = 0
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=65341, ...}) = 0
> old_mmap(NULL, 65341, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
> close(3) = 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "177ELF111 3 3 1 200^1"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=1243856, ...}) = 0
> old_mmap(NULL, 1254020, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000
> old_mmap(0x40150000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x127000) = 0x40150000
> old_mmap(0x40158000, 8836, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40158000
> close(3) = 0
> munmap(0x40018000, 65341) = 0
> brk(0) = 0x80545b4
> brk(0x80755b4) = 0x80755b4
> brk(0) = 0x80755b4
> brk(0x8076000) = 0x8076000
> time(NULL) = 1093877299
> open(".", O_RDONLY|O_LARGEFILE) = 3
> fchdir(3) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> chdir(".") = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> fstat64(4, {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> getdents64(4, /* 219 entries */, 8192) = 8168
> _llseek(4, 2144606367, [2144606367], SEEK_SET) = 0
> getdents64(4, /* 144 entries */, 8192) = 5584
> close(4) = 0
> brk(0) = 0x8076000
> brk(0) = 0x8076000
> brk(0x8075000) = 0x8075000
> brk(0) = 0x8075000
> write(2, "find: ", 6find: ) = 6
> write(2, ".", 1.) = 1
> write(2, ": Value too large for defined da"..., 39: Value too large for defined data type) = 39
> write(2, "n", 1 ) = 1
> fchdir(3) = 0
> exit_group(1) = ?
> poppins[reida]: ltrace -S find . -name "*.py"
> SYS_uname(0xbffff70c) = 0
> SYS_brk(NULL) = 0x80545b4
> SYS_mmap(0xbffff4ec, 34, 0x40016c40, 4096, 565) = 0x40017000
> SYS_access(0x40012de4, 0, 0x40016c40, 0x40016e78, 24) = -2
> SYS_open("/etc/ld.so.preload", 0, 010000226744) = -2
> SYS_open("/usr/site/lib/tls/i686/mmx/cmov/"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/mmx/libc."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/cmov/libc"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/mmx/cmov/libc."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/mmx/cmov/libc"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/cmov/libc.so."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/mmx/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = 0
> SYS_open("/etc/ld.so.cache", 0, 00) = 3
> SYS_fstat64(3, 0xbfffefe8, 0x40016c40, 0x40016e60, 2) = 0
> SYS_mmap(0xbfffefc8, 0, 0x40016c40, 3, 0x40016d30) = 0x40018000
> SYS_close(3) = 0
> SYS_access(0x40012de4, 0, 0x40016c40, 0, 524288) = -2
> SYS_open("/lib/libc.so.6", 0, 027777775257) = 3
> SYS_read(3, "177ELF 01 01 01", 512) = 512
> SYS_fstat64(3, 0xbffff098, 0x40016c40, 0x40016e60, 0) = 0
> SYS_mmap(0xbfffef1c, 3, 0x40016c40, 0x132284, 0xbfffef50) = 0x40028000
> SYS_mmap(0xbfffef1c, 0x40028000, 0x40016c40, 0x128000, 0xbfffef68) =
> 0x40150000
> SYS_mmap(0xbfffef1c, 8836, 0x40016c40, 50, 0xbfffef68) = 0x40158000
> SYS_close(3) = 0
> SYS_munmap(0x40018000, 65341) = 0
> __libc_start_main(0x80496a0, 4, 0xbffff954, 0x8052610, 0x8052670
> <unfinished ...>
> setlocale(6, "") = "C"
> bindtextdomain("findutils", "/usr/share/locale" <unfinished ...>
> SYS_brk(NULL) = 0x80545b4
> SYS_brk(0x80755b4) = 0x80755b4
> SYS_brk(NULL) = 0x80755b4
> SYS_brk(0x8076000) = 0x8076000
> <... bindtextdomain resumed> ) = "/usr/share/locale"
> textdomain("findutils") = "findutils"
> time(NULL <unfinished ...>
> SYS_time(0, 0, 0x8052710, 0, 0xbffff954) = 0x41333a1b
> <... time resumed> ) = 1093876251
> getenv("FIND_BLOCK_SIZE") = NULL
> getenv("BLOCK_SIZE") = NULL
> getenv("POSIXLY_CORRECT") = NULL
> strchr("-!(),", '.') = NULL
> strchr("-!(),", '-') = "-!(),"
> malloc(56) = 0x8054638
> strchr("-!(),", '-') = "-!(),"
> strcmp("!", "name") = -77
> strcmp("not", "name") = 14
> strcmp("(", "name") = -70
> strcmp(")", "name") = -69
> strcmp(",", "name") = -66
> strcmp("a", "name") = -13
> strcmp("amin", "name") = -13
> strcmp("and", "name") = -13
> strcmp("anewer", "name") = -13
> strcmp("atime", "name") = -13
> strcmp("cmin", "name") = -11
> strcmp("cnewer", "name") = -11
> strcmp("ctime", "name") = -11
> strcmp("daystart", "name") = -10
> strcmp("depth", "name") = -10
> strcmp("empty", "name") = -9
> strcmp("exec", "name") = -9
> strcmp("false", "name") = -8
> strcmp("fls", "name") = -8
> strcmp("follow", "name") = -8
> strcmp("fprint", "name") = -8
> strcmp("fprint0", "name") = -8
> strcmp("fprintf", "name") = -8
> strcmp("fstype", "name") = -8
> strcmp("gid", "name") = -7
> strcmp("group", "name") = -7
> strcmp("help", "name") = -6
> strcmp("-help", "name") = -65
> strcmp("ilname", "name") = -5
> strcmp("iname", "name") = -5
> strcmp("inum", "name") = -5
> strcmp("ipath", "name") = -5
> strcmp("iregex", "name") = -5
> strcmp("links", "name") = -2
> strcmp("lname", "name") = -2
> strcmp("ls", "name") = -2
> strcmp("maxdepth", "name") = -1
> strcmp("mindepth", "name") = -1
> strcmp("mmin", "name") = -1
> strcmp("mount", "name") = -1
> strcmp("mtime", "name") = -1
> strcmp("name", "name") = 0
> malloc(56) = 0x8054678
> malloc(56) = 0x80546b8
> malloc(56) = 0x80546f8
> malloc(56) = 0x8054738
> malloc(56) = 0x8054778
> open64(".", 0, 01001242620 <unfinished ...>
> SYS_open(".", 32768, 00) = 3
> <... open64 resumed> ) = 3
> fchdir(3 <unfinished ...>
> SYS_fchdir(3, 32768, 4, 0xbffffabb, 0xbffff954) = 0
> <... fchdir resumed> ) = 0
> __lxstat64(3, ".", 0x8054500 <unfinished ...>
> SYS_lstat64(0x8052865, 0x8054500, 0x40157550, 0x4015a008, 0x8054500) = 0
> <... __lxstat64 resumed> ) = 0
> strchr("-!(),", '.') = NULL
> strlen(".") = 1
> __lxstat64(3, ".", 0xbffff850 <unfinished ...>
> SYS_lstat64(0xbffffab9, 0xbffff850, 0x40157550, 0x4015a008, 0xbffff850)
> = 0
> <... __lxstat64 resumed> ) = 0
> chdir("." <unfinished ...>
> SYS_chdir(0xbffffab9, 0xbffff850, 1, 0, 0xbffffab9) = 0
> <... chdir resumed> ) = 0
> __lxstat64(3, ".", 0xbffff7f0 <unfinished ...>
> SYS_lstat64(0x8052865, 0xbffff7f0, 0x40157550, 0x4015a008, 0xbffff7f0) =
> 0
> <... __lxstat64 resumed> ) = 0
> __lxstat64(3, ".", 0xbffff750 <unfinished ...>
> SYS_lstat64(0x8052865, 0xbffff750, 0x40157550, 0x4015a008, 0xbffff750) =
> 0
> <... __lxstat64 resumed> ) = 0
> realloc(NULL, 512) = 0x80547b8
> fnmatch("*.py", ".", 4) = 1
> strlen(".") = 1
> __errno_location() = 0x40157900
> opendir("." <unfinished ...>
> SYS_open("/dev/null", 67584, 010005272520) = -20
> SYS_open(".", 100352, 010005272520) = 4
> SYS_fstat64(4, 0xbffff54c, 0x40157550, 0x4015a008, 0xbffff54c) = 0
> SYS_fcntl64(4, 2, 1, 1, 0x40157550) = 0
> <... opendir resumed> ) = 0x80549c0
> malloc(512) = 0x80569f8
> __errno_location() = 0x40157900
> readdir(0x80549c0 <unfinished ...>
> SYS_getdents64(4, 0x80549f0, 8192, 0x40157900, 0x40157550) = 208
> SYS__llseek(4, 0, 0x6c2c6bd7, 0xbffff51c, 0) = 0
> <... readdir resumed> ) = 0x80549f0
> readdir(0x80549c0) = 0x8054a00
> readdir(0x80549c0) = 0x8054a10
> strlen("stuff.py~") = 9
> memcpy(0x80569f8, "stuff.py~", 10) = 0x80569f8
> readdir(0x80549c0) = 0x8054a28
> strlen("stuff.pyc") = 9
> memcpy(0x8056a02, "stuff.pyc", 10) = 0x8056a02
> readdir(0x80549c0) = 0x8054a40
> strlen("test.py") = 7
> memcpy(0x8056a0c, "test.py", 8) = 0x8056a0c
> readdir(0x80549c0) = 0x8054a58
> strlen("test.py~") = 8
> memcpy(0x8056a14, "test.py~", 9) = 0x8056a14
> readdir(0x80549c0 <unfinished ...>
> SYS_getdents64(4, 0x80549f0, 8192, 0x40157900, 0x40157550) = 32
> <... readdir resumed> ) = NULL
> __errno_location() = 0x40157900
> closedir(0x80549c0 <unfinished ...>
> SYS_close(4) = 0
> <... closedir resumed> ) = 0
> free(0x80569f8 <unfinished ...>
> SYS_brk(NULL) = 0x8076000
> SYS_brk(NULL) = 0x8076000
> SYS_brk(0x8075000) = 0x8075000
> SYS_brk(NULL) = 0x8075000
> <... free resumed> ) = <void>
> error(0, 75, 0x8053b72, 0xbffffab9, 0x4002fa10 <unfinished ...>
> SYS_write(2, "find: ", 6find: ) = 6
> SYS_write(2, ".", 1.) = 1
> SYS_write(2, ": Value too large for defined da"..., 39: Value too large
> for defined data type) = 39
> SYS_write(2, "n", 1
> ) = 1
> <... error resumed> ) = 0
> fchdir(3 <unfinished ...>
> SYS_fchdir(3, 0, 0, 0, 0xbffffab9) = 0
> <... fchdir resumed> ) = 0
> strchr("-!(),", '-') = "-!(),"
> exit(1 <unfinished ...>
> SYS_exit_group(1) = <void>
> SYS_exit(1 <unfinished ...>
> +++ exited (status 1) +++
> poppins[reida]:
-------------------------------------------------------
Date: Mon 04/05/04 at 16:31 By: James Youngman <jay>
The likely difference between the two versions of find is that they use a different version of gnulib, and the updated version is now sensitive to this problem. Alternatively, maybe it's a glibc difference. Certainly the differences between the find application code is minimal.
Looking at the ltrace output, it looks like readdir() is failing. The likely bit of affected code is gnulib's savedir.c. That certainly should faiil if readdir() fails.
I suspect that somewhere in there is a filename whose base
name is more than 256 characters. To find out, please try this (on either the client or the server):
ls -R1 | awk '(length > 200) {print length, $0;}' | sort -n | tail
Try picking the last filename from the above and invoking find directly on it. The idea here is to pin things down to one path name that successfully reproduces the error.
Lastly, the output of "ltrace" isn't very helpful about the data that's returned from the system calls. What do you get if you use "strace"? What about "ltrace -S"?
CC List
-------
CC Address | Comment
------------------------------------+-----------------------------
241538 --AT-- bugs --DOT-- debian --DOT-- org | original report
andrewreid<andrew --DOT-- reid --AT-- nist --DOT-- gov> | Bug forwarded to upstream authors
File Attachments
-------------------
-------------------------------------------------------
Date: Mon 04/05/04 at 15:29 Name: findbug.ltrace Size: 30.51KB By: ametzler
ltrace output
http://savannah.gnu.org/bugs/download.php?item_id=8455&item_file_id=1169
For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=8455>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Metzler <ametzler@debian.org>:
Bug#241538; Package findutils.
(full text, mbox, link).
Acknowledgement sent to James Youngman <noreply@savannah.gnu.org>:
Extra info received and forwarded to list. Copy sent to Andreas Metzler <ametzler@debian.org>.
(full text, mbox, link).
Message #27 received at 241538@bugs.debian.org (full text, mbox, reply):
This mail is an automated notification from the bugs tracker
of the project: findutils.
/**************************************************************************/
[bugs #8455] Latest Modifications:
Changes by:
James Youngman <jay@gnu.org>
'Date:
Thu 12/02/2004 at 09:11 (GMT)
------------------ Additional Follow-up Comments ----------------------------
See also http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141167
/**************************************************************************/
[bugs #8455] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8455>
Project: findutils
Submitted by: Andreas Metzler
On: Mon 04/05/2004 at 15:29
Category: find
Severity: 5 - Average
Item Group: None
Resolution: None
Privacy: Public
Assigned to: None
Originator Name:
Originator Email:
Status: Open
Release: None
Fixed Release: None
Summary: anomaly on large xfs filesystems
Original Submission: This is a copy of <http://bugs.debian.org/241538>.
Andrew Reid writes:
--------------------------
Version: 4.1.20-3
I am having a rather strange difficulty with the "find" command.
For many paths on my system, including all paths in my
account, I get:
> # find <path> -print
> find: <path>: Value too large for defined data type
The failure occurs in some directories but not others, as described
below.
The set-up of the machine is such that user home directories can be
accessed by multiple routes from the start of the file system. I am
not certain that this is relevant, but describe it here for
completeness.
Users' actual home directories are divided into several numbered
"home" directories from the root, like this: /u/home<n>/<user>/
All user home directories are accessible via symlinks from
/u/users/<user> -> /u/home<n>/<user>
There is also a symlink at the root of the filesystem,
/users -> /u/users
The client is an x86 machine. The filesystems are remotely mounted
"xfs" file systems, mounted via NFS from an SGI file server. Each
home<n> subdirectory is separately mounted on the client by way of an
automounter. Most of these reside on separate disks on the server,
except for home1 and home2, which share a physical disk on the server.
The problem occurs for some of the /u/home<n>/ directories, but not
others.
All of these directories are exported identically (to each other) from
the file server, and imported identically by the client. There are
hardware differences between the mounted disks, which correlate with
the "find" problem -- home directories which occupy 48GB disks and use
more than 28GB of them seem to have this problem. The problem is also
common to all of the largest filesystems.
On a Debian "stable" client, importing the same file systems from the
same file server, running the same kernel, but using "find" from
version 4.1.7-2 of findutils, the problem does not occur.
On all systems, these calls work.
# find /u -maxdepth 1
# find /u/users -maxdepth 1
On the problem system in the problem directories, these calls:
# find /u/home<n> -maxdepth 1
fail with the "Value too large" error -- this path argument
is the direct path to the home directory.
Although the filesystem and automounter configuration on these
machines is not trivial, it is nevertheless identical between "stable"
and "testing" machines, and the "find" bug occurs only on the
"testing" machines. There is circumstantial evidence that the problem
involves large xfs filesystems.
--------------------------
He later provided me with the ltrace I am attaching.
thanks, cu andreas
Follow-up Comments
------------------
-------------------------------------------------------
Date: Thu 12/02/2004 at 09:11 By: James Youngman <jay>
See also http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141167
-------------------------------------------------------
Date: Mon 11/22/2004 at 00:45 By: James Youngman <jay>
I've created a local XFS filesystem with a couple of million files in it (one directory has over 900,000 entries). find searches it in about 15 seconds without failing. I'm not using NFS though.
-------------------------------------------------------
Date: Sat 10/02/2004 at 10:48 By: James Youngman <jay>
OK, having looked at the trace output, I still suspect that it is savedir() which is failing. I have a small number of questions.
1. If you use "tar" to copy the directory tree to a local filesystem, can you reproduce the problem? Don't forgert to use the "p" option when unpacking.
The other checks involve getting hold of a copy of the source. If you're not confident with compiling source code, don't worry about it. Otherwise, I have a couple of other suggested tests:
a) Change error() [in file error.c] so that it calls abort(). Then use GDB to get a stack backtrace from the coredump. Send me a copy of the stack backtrace. For the lower levels of the backtrace (say 3 as a guideline) show me which line that corresponds to (the will avoid problems caused by us looking at different versions of the code).
b) Use GDB to single-step through savedir() to figure out why it fails - if indeed (b) shows that it has failed.
Sorry to make you do all the work, but I can't reproduce the problem here.
-------------------------------------------------------
Date: Mon 08/30/2004 at 15:54 By: 0 <None>
On Mon, Aug 09, 2004 at 01:01:12PM +0200, Andreas Metzler wrote:
> On 2004-04-01 Andrew Reid <Andrew.Reid@nist.gov> wrote:
> > Package: findutils
> > Version: 4.1.20-3
>
> > I am having a rather strange difficulty with the "find" command.
>
> > For many paths on my system, including all paths in my
> > account, I get:
>
> > > # find <path> -print
> > > find: <path>: Value too large for defined data type
> [...]
>
Thanks for the reply and sorry about my delay in replying -- partially
it's vacation season, and partially I've just been doing other stuff.
> While browsing upstream's bugtracker where I had forwarded the bug to
> I found this in
> http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=8455
>
> -----------------------
> The likely difference between the two versions of find is that they
> use a different version of gnulib, and the updated version is now
> sensitive to this problem. Alternatively, maybe it's a glibc
> difference. Certainly the differences between the find application
> code is minimal.
>
> Looking at the ltrace output, it looks like readdir() is failing. The
> likely bit of affected code is gnulib's savedir.c. That certainly
> should faiil if readdir() fails.
>
> I suspect that somewhere in there is a filename whose base name is
> more than 256 characters. To find out, please try this (on either the
> client or the server):
>
> ls -R1 | awk '(length > 200) {print length, $0;}' | sort -n | tail
This suspicion is not confirmed, alas -- the awk returns nothing
with length > 200. To check that it worked at all, I ratcheted
down the number, and I start to get lots of stuff once it's
less than around 50. Nothing longer than 100. I made no attempt
to refine it beyond that.
> Try picking the last filename from the above and invoking find
> directly on it. The idea here is to pin things down to one path name
> that successfully reproduces the error.
I appreciate the need for diagnosing under controlled conditions,
so I've picked a directory to run it, which I will use for future
tests, if any...
> Lastly, the output of "ltrace" isn't very helpful about the data
> that's returned from the system calls. What do you get if you use
> "strace"? What about "ltrace -S"?
Here's another crack at it -- in case you're curious, this was
test code for what, exactly, Python does to its internal search
paths at start-up time.
Also, recall that the filesystem being examined is an SGI XFS
filesystem which is NFS mounted by the Debian Sarge linux box
which is actually running the "find" command.
The directory:
> poppins[reida]: ls -al
> total 24
> drwxr-xr-x 2 reida user 95 Feb 3 2004 ./
> drwxr-xr-x 22 reida user 4096 Aug 25 20:35 ../
> -rw-r--r-- 1 reida user 20 Feb 3 2004 stuff.py
> -rw-r--r-- 1 reida user 229 Feb 3 2004 stuff.pyc
> -rw-r--r-- 1 reida user 44 Feb 3 2004 stuff.py~
> -rwxr-xr-- 1 reida user 230 Feb 3 2004 test.py*
> -rw-r--r-- 1 reida user 95 Feb 3 2004 test.py~
Debian Woody, with strace output afterwards.
> jeeves[reida]: find . -name "*.py"
> ./test.py
> ./stuff.py
> jeeves[reida]: strace find . -name "*.py"
> execve("/usr/bin/find", ["find", ".", "-name", "*.py"], [/* 35 vars */]) = 0
> uname({sys="Linux", node="jeeves", ...}) = 0
> brk(0) = 0x8053d54
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib", {st_mode=S_IFDIR|0755, st_size=776, ...}) = 0
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=41861, ...}) = 0
> old_mmap(NULL, 41861, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
> close(3) = 0
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "177ELF111 3 3 1 30222"..., 1024) = 1024
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1153784, ...}) = 0
> old_mmap(NULL, 1166560, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001f000
> mprotect(0x40132000, 40160, PROT_NONE) = 0
> old_mmap(0x40132000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x113000) = 0x40132000
> old_mmap(0x40138000, 15584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40138000
> close(3) = 0
> munmap(0x40014000, 41861) = 0
> brk(0) = 0x8053d54
> brk(0x8053d7c) = 0x8053d7c
> brk(0x8054000) = 0x8054000
> time(NULL) = 1093877075
> open(".", O_RDONLY|O_LARGEFILE) = 3
> fchdir(3) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> chdir(".") = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> brk(0x8055000) = 0x8055000
> open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> fstat64(4, {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> brk(0x8058000) = 0x8058000
> getdents64(0x4, 0x8054148, 0x2000, 0) = 208
> getdents64(0x4, 0x8054148, 0x2000, 0) = 0
> close(4) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
> write(1, "./test.pyn", 10./test.py) = 10
> write(1, "./stuff.pyn", 11./stuff.py) = 11
> fchdir(3) = 0
> munmap(0x40014000, 4096) = 0
> _exit(0) = ?
... then Debian Sarge: Since this is the system with the problem,
I have included both strace and ltrace -S output -- they seem to not
quite be the same, so you may of course use whichever is most useful
to you.
> poppins[reida]: find . -name "*.py"
> find: .: Value too large for defined data type
> poppins[reida]: strace find . -name "*.py"
> execve("/usr/bin/find", ["find", ".", "-name", "*.py"], [/* 46 vars */]) = 0
> uname({sys="Linux", node="poppins", ...}) = 0
> brk(0) = 0x80545b4
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib", {st_mode=S_IFDIR|0755, st_size=776, ...}) = 0
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=65341, ...}) = 0
> old_mmap(NULL, 65341, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
> close(3) = 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "177ELF111 3 3 1 200^1"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=1243856, ...}) = 0
> old_mmap(NULL, 1254020, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000
> old_mmap(0x40150000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x127000) = 0x40150000
> old_mmap(0x40158000, 8836, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40158000
> close(3) = 0
> munmap(0x40018000, 65341) = 0
> brk(0) = 0x80545b4
> brk(0x80755b4) = 0x80755b4
> brk(0) = 0x80755b4
> brk(0x8076000) = 0x8076000
> time(NULL) = 1093877299
> open(".", O_RDONLY|O_LARGEFILE) = 3
> fchdir(3) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> chdir(".") = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> fstat64(4, {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> getdents64(4, /* 219 entries */, 8192) = 8168
> _llseek(4, 2144606367, [2144606367], SEEK_SET) = 0
> getdents64(4, /* 144 entries */, 8192) = 5584
> close(4) = 0
> brk(0) = 0x8076000
> brk(0) = 0x8076000
> brk(0x8075000) = 0x8075000
> brk(0) = 0x8075000
> write(2, "find: ", 6find: ) = 6
> write(2, ".", 1.) = 1
> write(2, ": Value too large for defined da"..., 39: Value too large for defined data type) = 39
> write(2, "n", 1 ) = 1
> fchdir(3) = 0
> exit_group(1) = ?
> poppins[reida]: ltrace -S find . -name "*.py"
> SYS_uname(0xbffff70c) = 0
> SYS_brk(NULL) = 0x80545b4
> SYS_mmap(0xbffff4ec, 34, 0x40016c40, 4096, 565) = 0x40017000
> SYS_access(0x40012de4, 0, 0x40016c40, 0x40016e78, 24) = -2
> SYS_open("/etc/ld.so.preload", 0, 010000226744) = -2
> SYS_open("/usr/site/lib/tls/i686/mmx/cmov/"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/mmx/libc."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/cmov/libc"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/mmx/cmov/libc."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/mmx/cmov/libc"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/cmov/libc.so."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/mmx/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = 0
> SYS_open("/etc/ld.so.cache", 0, 00) = 3
> SYS_fstat64(3, 0xbfffefe8, 0x40016c40, 0x40016e60, 2) = 0
> SYS_mmap(0xbfffefc8, 0, 0x40016c40, 3, 0x40016d30) = 0x40018000
> SYS_close(3) = 0
> SYS_access(0x40012de4, 0, 0x40016c40, 0, 524288) = -2
> SYS_open("/lib/libc.so.6", 0, 027777775257) = 3
> SYS_read(3, "177ELF 01 01 01", 512) = 512
> SYS_fstat64(3, 0xbffff098, 0x40016c40, 0x40016e60, 0) = 0
> SYS_mmap(0xbfffef1c, 3, 0x40016c40, 0x132284, 0xbfffef50) = 0x40028000
> SYS_mmap(0xbfffef1c, 0x40028000, 0x40016c40, 0x128000, 0xbfffef68) =
> 0x40150000
> SYS_mmap(0xbfffef1c, 8836, 0x40016c40, 50, 0xbfffef68) = 0x40158000
> SYS_close(3) = 0
> SYS_munmap(0x40018000, 65341) = 0
> __libc_start_main(0x80496a0, 4, 0xbffff954, 0x8052610, 0x8052670
> <unfinished ...>
> setlocale(6, "") = "C"
> bindtextdomain("findutils", "/usr/share/locale" <unfinished ...>
> SYS_brk(NULL) = 0x80545b4
> SYS_brk(0x80755b4) = 0x80755b4
> SYS_brk(NULL) = 0x80755b4
> SYS_brk(0x8076000) = 0x8076000
> <... bindtextdomain resumed> ) = "/usr/share/locale"
> textdomain("findutils") = "findutils"
> time(NULL <unfinished ...>
> SYS_time(0, 0, 0x8052710, 0, 0xbffff954) = 0x41333a1b
> <... time resumed> ) = 1093876251
> getenv("FIND_BLOCK_SIZE") = NULL
> getenv("BLOCK_SIZE") = NULL
> getenv("POSIXLY_CORRECT") = NULL
> strchr("-!(),", '.') = NULL
> strchr("-!(),", '-') = "-!(),"
> malloc(56) = 0x8054638
> strchr("-!(),", '-') = "-!(),"
> strcmp("!", "name") = -77
> strcmp("not", "name") = 14
> strcmp("(", "name") = -70
> strcmp(")", "name") = -69
> strcmp(",", "name") = -66
> strcmp("a", "name") = -13
> strcmp("amin", "name") = -13
> strcmp("and", "name") = -13
> strcmp("anewer", "name") = -13
> strcmp("atime", "name") = -13
> strcmp("cmin", "name") = -11
> strcmp("cnewer", "name") = -11
> strcmp("ctime", "name") = -11
> strcmp("daystart", "name") = -10
> strcmp("depth", "name") = -10
> strcmp("empty", "name") = -9
> strcmp("exec", "name") = -9
> strcmp("false", "name") = -8
> strcmp("fls", "name") = -8
> strcmp("follow", "name") = -8
> strcmp("fprint", "name") = -8
> strcmp("fprint0", "name") = -8
> strcmp("fprintf", "name") = -8
> strcmp("fstype", "name") = -8
> strcmp("gid", "name") = -7
> strcmp("group", "name") = -7
> strcmp("help", "name") = -6
> strcmp("-help", "name") = -65
> strcmp("ilname", "name") = -5
> strcmp("iname", "name") = -5
> strcmp("inum", "name") = -5
> strcmp("ipath", "name") = -5
> strcmp("iregex", "name") = -5
> strcmp("links", "name") = -2
> strcmp("lname", "name") = -2
> strcmp("ls", "name") = -2
> strcmp("maxdepth", "name") = -1
> strcmp("mindepth", "name") = -1
> strcmp("mmin", "name") = -1
> strcmp("mount", "name") = -1
> strcmp("mtime", "name") = -1
> strcmp("name", "name") = 0
> malloc(56) = 0x8054678
> malloc(56) = 0x80546b8
> malloc(56) = 0x80546f8
> malloc(56) = 0x8054738
> malloc(56) = 0x8054778
> open64(".", 0, 01001242620 <unfinished ...>
> SYS_open(".", 32768, 00) = 3
> <... open64 resumed> ) = 3
> fchdir(3 <unfinished ...>
> SYS_fchdir(3, 32768, 4, 0xbffffabb, 0xbffff954) = 0
> <... fchdir resumed> ) = 0
> __lxstat64(3, ".", 0x8054500 <unfinished ...>
> SYS_lstat64(0x8052865, 0x8054500, 0x40157550, 0x4015a008, 0x8054500) = 0
> <... __lxstat64 resumed> ) = 0
> strchr("-!(),", '.') = NULL
> strlen(".") = 1
> __lxstat64(3, ".", 0xbffff850 <unfinished ...>
> SYS_lstat64(0xbffffab9, 0xbffff850, 0x40157550, 0x4015a008, 0xbffff850)
> = 0
> <... __lxstat64 resumed> ) = 0
> chdir("." <unfinished ...>
> SYS_chdir(0xbffffab9, 0xbffff850, 1, 0, 0xbffffab9) = 0
> <... chdir resumed> ) = 0
> __lxstat64(3, ".", 0xbffff7f0 <unfinished ...>
> SYS_lstat64(0x8052865, 0xbffff7f0, 0x40157550, 0x4015a008, 0xbffff7f0) =
> 0
> <... __lxstat64 resumed> ) = 0
> __lxstat64(3, ".", 0xbffff750 <unfinished ...>
> SYS_lstat64(0x8052865, 0xbffff750, 0x40157550, 0x4015a008, 0xbffff750) =
> 0
> <... __lxstat64 resumed> ) = 0
> realloc(NULL, 512) = 0x80547b8
> fnmatch("*.py", ".", 4) = 1
> strlen(".") = 1
> __errno_location() = 0x40157900
> opendir("." <unfinished ...>
> SYS_open("/dev/null", 67584, 010005272520) = -20
> SYS_open(".", 100352, 010005272520) = 4
> SYS_fstat64(4, 0xbffff54c, 0x40157550, 0x4015a008, 0xbffff54c) = 0
> SYS_fcntl64(4, 2, 1, 1, 0x40157550) = 0
> <... opendir resumed> ) = 0x80549c0
> malloc(512) = 0x80569f8
> __errno_location() = 0x40157900
> readdir(0x80549c0 <unfinished ...>
> SYS_getdents64(4, 0x80549f0, 8192, 0x40157900, 0x40157550) = 208
> SYS__llseek(4, 0, 0x6c2c6bd7, 0xbffff51c, 0) = 0
> <... readdir resumed> ) = 0x80549f0
> readdir(0x80549c0) = 0x8054a00
> readdir(0x80549c0) = 0x8054a10
> strlen("stuff.py~") = 9
> memcpy(0x80569f8, "stuff.py~", 10) = 0x80569f8
> readdir(0x80549c0) = 0x8054a28
> strlen("stuff.pyc") = 9
> memcpy(0x8056a02, "stuff.pyc", 10) = 0x8056a02
> readdir(0x80549c0) = 0x8054a40
> strlen("test.py") = 7
> memcpy(0x8056a0c, "test.py", 8) = 0x8056a0c
> readdir(0x80549c0) = 0x8054a58
> strlen("test.py~") = 8
> memcpy(0x8056a14, "test.py~", 9) = 0x8056a14
> readdir(0x80549c0 <unfinished ...>
> SYS_getdents64(4, 0x80549f0, 8192, 0x40157900, 0x40157550) = 32
> <... readdir resumed> ) = NULL
> __errno_location() = 0x40157900
> closedir(0x80549c0 <unfinished ...>
> SYS_close(4) = 0
> <... closedir resumed> ) = 0
> free(0x80569f8 <unfinished ...>
> SYS_brk(NULL) = 0x8076000
> SYS_brk(NULL) = 0x8076000
> SYS_brk(0x8075000) = 0x8075000
> SYS_brk(NULL) = 0x8075000
> <... free resumed> ) = <void>
> error(0, 75, 0x8053b72, 0xbffffab9, 0x4002fa10 <unfinished ...>
> SYS_write(2, "find: ", 6find: ) = 6
> SYS_write(2, ".", 1.) = 1
> SYS_write(2, ": Value too large for defined da"..., 39: Value too large
> for defined data type) = 39
> SYS_write(2, "n", 1
> ) = 1
> <... error resumed> ) = 0
> fchdir(3 <unfinished ...>
> SYS_fchdir(3, 0, 0, 0, 0xbffffab9) = 0
> <... fchdir resumed> ) = 0
> strchr("-!(),", '-') = "-!(),"
> exit(1 <unfinished ...>
> SYS_exit_group(1) = <void>
> SYS_exit(1 <unfinished ...>
> +++ exited (status 1) +++
> poppins[reida]:
-------------------------------------------------------
Date: Mon 04/05/2004 at 16:31 By: James Youngman <jay>
The likely difference between the two versions of find is that they use a different version of gnulib, and the updated version is now sensitive to this problem. Alternatively, maybe it's a glibc difference. Certainly the differences between the find application code is minimal.
Looking at the ltrace output, it looks like readdir() is failing. The likely bit of affected code is gnulib's savedir.c. That certainly should faiil if readdir() fails.
I suspect that somewhere in there is a filename whose base
name is more than 256 characters. To find out, please try this (on either the client or the server):
ls -R1 | awk '(length > 200) {print length, $0;}' | sort -n | tail
Try picking the last filename from the above and invoking find directly on it. The idea here is to pin things down to one path name that successfully reproduces the error.
Lastly, the output of "ltrace" isn't very helpful about the data that's returned from the system calls. What do you get if you use "strace"? What about "ltrace -S"?
CC List
-------
CC Address | Comment
------------------------------------+-----------------------------
timwaugh<twaugh --AT-- redhat --DOT-- com> | Handling similar bug for Red Hat.
241538 --AT-- bugs --DOT-- debian --DOT-- org | original report
andrewreid<andrew --DOT-- reid --AT-- nist --DOT-- gov> | Bug forwarded to upstream authors
File Attachments
-------------------
-------------------------------------------------------
Date: Mon 04/05/2004 at 15:29 Name: findbug.ltrace Size: 30.51KB By: ametzler
ltrace output
http://savannah.gnu.org/bugs/download.php?item_id=8455&item_file_id=1169
For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=8455>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Metzler <ametzler@debian.org>:
Bug#241538; Package findutils.
(full text, mbox, link).
Acknowledgement sent to Tim Waugh <noreply@savannah.gnu.org>:
Extra info received and forwarded to list. Copy sent to Andreas Metzler <ametzler@debian.org>.
(full text, mbox, link).
Message #32 received at 241538@bugs.debian.org (full text, mbox, reply):
This mail is an automated notification from the bugs tracker
of the project: findutils.
/**************************************************************************/
[bugs #8455] Latest Modifications:
Changes by:
Tim Waugh <twaugh@redhat.com>
'Date:
Thu 12/02/2004 at 10:02 (GMT)
------------------ Additional Follow-up Comments ----------------------------
See also:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141167
/**************************************************************************/
[bugs #8455] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8455>
Project: findutils
Submitted by: Andreas Metzler
On: Mon 04/05/2004 at 15:29
Category: find
Severity: 5 - Average
Item Group: None
Resolution: None
Privacy: Public
Assigned to: None
Originator Name:
Originator Email:
Status: Open
Release: None
Fixed Release: None
Summary: anomaly on large xfs filesystems
Original Submission: This is a copy of <http://bugs.debian.org/241538>.
Andrew Reid writes:
--------------------------
Version: 4.1.20-3
I am having a rather strange difficulty with the "find" command.
For many paths on my system, including all paths in my
account, I get:
> # find <path> -print
> find: <path>: Value too large for defined data type
The failure occurs in some directories but not others, as described
below.
The set-up of the machine is such that user home directories can be
accessed by multiple routes from the start of the file system. I am
not certain that this is relevant, but describe it here for
completeness.
Users' actual home directories are divided into several numbered
"home" directories from the root, like this: /u/home<n>/<user>/
All user home directories are accessible via symlinks from
/u/users/<user> -> /u/home<n>/<user>
There is also a symlink at the root of the filesystem,
/users -> /u/users
The client is an x86 machine. The filesystems are remotely mounted
"xfs" file systems, mounted via NFS from an SGI file server. Each
home<n> subdirectory is separately mounted on the client by way of an
automounter. Most of these reside on separate disks on the server,
except for home1 and home2, which share a physical disk on the server.
The problem occurs for some of the /u/home<n>/ directories, but not
others.
All of these directories are exported identically (to each other) from
the file server, and imported identically by the client. There are
hardware differences between the mounted disks, which correlate with
the "find" problem -- home directories which occupy 48GB disks and use
more than 28GB of them seem to have this problem. The problem is also
common to all of the largest filesystems.
On a Debian "stable" client, importing the same file systems from the
same file server, running the same kernel, but using "find" from
version 4.1.7-2 of findutils, the problem does not occur.
On all systems, these calls work.
# find /u -maxdepth 1
# find /u/users -maxdepth 1
On the problem system in the problem directories, these calls:
# find /u/home<n> -maxdepth 1
fail with the "Value too large" error -- this path argument
is the direct path to the home directory.
Although the filesystem and automounter configuration on these
machines is not trivial, it is nevertheless identical between "stable"
and "testing" machines, and the "find" bug occurs only on the
"testing" machines. There is circumstantial evidence that the problem
involves large xfs filesystems.
--------------------------
He later provided me with the ltrace I am attaching.
thanks, cu andreas
Follow-up Comments
------------------
-------------------------------------------------------
Date: Thu 12/02/2004 at 10:02 By: Tim Waugh <twaugh>
See also:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141167
-------------------------------------------------------
Date: Thu 12/02/2004 at 09:11 By: James Youngman <jay>
See also http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141167
-------------------------------------------------------
Date: Mon 11/22/2004 at 00:45 By: James Youngman <jay>
I've created a local XFS filesystem with a couple of million files in it (one directory has over 900,000 entries). find searches it in about 15 seconds without failing. I'm not using NFS though.
-------------------------------------------------------
Date: Sat 10/02/2004 at 10:48 By: James Youngman <jay>
OK, having looked at the trace output, I still suspect that it is savedir() which is failing. I have a small number of questions.
1. If you use "tar" to copy the directory tree to a local filesystem, can you reproduce the problem? Don't forgert to use the "p" option when unpacking.
The other checks involve getting hold of a copy of the source. If you're not confident with compiling source code, don't worry about it. Otherwise, I have a couple of other suggested tests:
a) Change error() [in file error.c] so that it calls abort(). Then use GDB to get a stack backtrace from the coredump. Send me a copy of the stack backtrace. For the lower levels of the backtrace (say 3 as a guideline) show me which line that corresponds to (the will avoid problems caused by us looking at different versions of the code).
b) Use GDB to single-step through savedir() to figure out why it fails - if indeed (b) shows that it has failed.
Sorry to make you do all the work, but I can't reproduce the problem here.
-------------------------------------------------------
Date: Mon 08/30/2004 at 15:54 By: 0 <None>
On Mon, Aug 09, 2004 at 01:01:12PM +0200, Andreas Metzler wrote:
> On 2004-04-01 Andrew Reid <Andrew.Reid@nist.gov> wrote:
> > Package: findutils
> > Version: 4.1.20-3
>
> > I am having a rather strange difficulty with the "find" command.
>
> > For many paths on my system, including all paths in my
> > account, I get:
>
> > > # find <path> -print
> > > find: <path>: Value too large for defined data type
> [...]
>
Thanks for the reply and sorry about my delay in replying -- partially
it's vacation season, and partially I've just been doing other stuff.
> While browsing upstream's bugtracker where I had forwarded the bug to
> I found this in
> http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=8455
>
> -----------------------
> The likely difference between the two versions of find is that they
> use a different version of gnulib, and the updated version is now
> sensitive to this problem. Alternatively, maybe it's a glibc
> difference. Certainly the differences between the find application
> code is minimal.
>
> Looking at the ltrace output, it looks like readdir() is failing. The
> likely bit of affected code is gnulib's savedir.c. That certainly
> should faiil if readdir() fails.
>
> I suspect that somewhere in there is a filename whose base name is
> more than 256 characters. To find out, please try this (on either the
> client or the server):
>
> ls -R1 | awk '(length > 200) {print length, $0;}' | sort -n | tail
This suspicion is not confirmed, alas -- the awk returns nothing
with length > 200. To check that it worked at all, I ratcheted
down the number, and I start to get lots of stuff once it's
less than around 50. Nothing longer than 100. I made no attempt
to refine it beyond that.
> Try picking the last filename from the above and invoking find
> directly on it. The idea here is to pin things down to one path name
> that successfully reproduces the error.
I appreciate the need for diagnosing under controlled conditions,
so I've picked a directory to run it, which I will use for future
tests, if any...
> Lastly, the output of "ltrace" isn't very helpful about the data
> that's returned from the system calls. What do you get if you use
> "strace"? What about "ltrace -S"?
Here's another crack at it -- in case you're curious, this was
test code for what, exactly, Python does to its internal search
paths at start-up time.
Also, recall that the filesystem being examined is an SGI XFS
filesystem which is NFS mounted by the Debian Sarge linux box
which is actually running the "find" command.
The directory:
> poppins[reida]: ls -al
> total 24
> drwxr-xr-x 2 reida user 95 Feb 3 2004 ./
> drwxr-xr-x 22 reida user 4096 Aug 25 20:35 ../
> -rw-r--r-- 1 reida user 20 Feb 3 2004 stuff.py
> -rw-r--r-- 1 reida user 229 Feb 3 2004 stuff.pyc
> -rw-r--r-- 1 reida user 44 Feb 3 2004 stuff.py~
> -rwxr-xr-- 1 reida user 230 Feb 3 2004 test.py*
> -rw-r--r-- 1 reida user 95 Feb 3 2004 test.py~
Debian Woody, with strace output afterwards.
> jeeves[reida]: find . -name "*.py"
> ./test.py
> ./stuff.py
> jeeves[reida]: strace find . -name "*.py"
> execve("/usr/bin/find", ["find", ".", "-name", "*.py"], [/* 35 vars */]) = 0
> uname({sys="Linux", node="jeeves", ...}) = 0
> brk(0) = 0x8053d54
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib", {st_mode=S_IFDIR|0755, st_size=776, ...}) = 0
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=41861, ...}) = 0
> old_mmap(NULL, 41861, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
> close(3) = 0
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "177ELF111 3 3 1 30222"..., 1024) = 1024
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1153784, ...}) = 0
> old_mmap(NULL, 1166560, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001f000
> mprotect(0x40132000, 40160, PROT_NONE) = 0
> old_mmap(0x40132000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x113000) = 0x40132000
> old_mmap(0x40138000, 15584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40138000
> close(3) = 0
> munmap(0x40014000, 41861) = 0
> brk(0) = 0x8053d54
> brk(0x8053d7c) = 0x8053d7c
> brk(0x8054000) = 0x8054000
> time(NULL) = 1093877075
> open(".", O_RDONLY|O_LARGEFILE) = 3
> fchdir(3) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> chdir(".") = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> brk(0x8055000) = 0x8055000
> open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> fstat64(4, {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> brk(0x8058000) = 0x8058000
> getdents64(0x4, 0x8054148, 0x2000, 0) = 208
> getdents64(0x4, 0x8054148, 0x2000, 0) = 0
> close(4) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
> write(1, "./test.pyn", 10./test.py) = 10
> write(1, "./stuff.pyn", 11./stuff.py) = 11
> fchdir(3) = 0
> munmap(0x40014000, 4096) = 0
> _exit(0) = ?
... then Debian Sarge: Since this is the system with the problem,
I have included both strace and ltrace -S output -- they seem to not
quite be the same, so you may of course use whichever is most useful
to you.
> poppins[reida]: find . -name "*.py"
> find: .: Value too large for defined data type
> poppins[reida]: strace find . -name "*.py"
> execve("/usr/bin/find", ["find", ".", "-name", "*.py"], [/* 46 vars */]) = 0
> uname({sys="Linux", node="poppins", ...}) = 0
> brk(0) = 0x80545b4
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib", {st_mode=S_IFDIR|0755, st_size=776, ...}) = 0
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=65341, ...}) = 0
> old_mmap(NULL, 65341, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
> close(3) = 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "177ELF111 3 3 1 200^1"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=1243856, ...}) = 0
> old_mmap(NULL, 1254020, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000
> old_mmap(0x40150000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x127000) = 0x40150000
> old_mmap(0x40158000, 8836, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40158000
> close(3) = 0
> munmap(0x40018000, 65341) = 0
> brk(0) = 0x80545b4
> brk(0x80755b4) = 0x80755b4
> brk(0) = 0x80755b4
> brk(0x8076000) = 0x8076000
> time(NULL) = 1093877299
> open(".", O_RDONLY|O_LARGEFILE) = 3
> fchdir(3) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> chdir(".") = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> fstat64(4, {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> getdents64(4, /* 219 entries */, 8192) = 8168
> _llseek(4, 2144606367, [2144606367], SEEK_SET) = 0
> getdents64(4, /* 144 entries */, 8192) = 5584
> close(4) = 0
> brk(0) = 0x8076000
> brk(0) = 0x8076000
> brk(0x8075000) = 0x8075000
> brk(0) = 0x8075000
> write(2, "find: ", 6find: ) = 6
> write(2, ".", 1.) = 1
> write(2, ": Value too large for defined da"..., 39: Value too large for defined data type) = 39
> write(2, "n", 1 ) = 1
> fchdir(3) = 0
> exit_group(1) = ?
> poppins[reida]: ltrace -S find . -name "*.py"
> SYS_uname(0xbffff70c) = 0
> SYS_brk(NULL) = 0x80545b4
> SYS_mmap(0xbffff4ec, 34, 0x40016c40, 4096, 565) = 0x40017000
> SYS_access(0x40012de4, 0, 0x40016c40, 0x40016e78, 24) = -2
> SYS_open("/etc/ld.so.preload", 0, 010000226744) = -2
> SYS_open("/usr/site/lib/tls/i686/mmx/cmov/"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/mmx/libc."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/cmov/libc"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/mmx/cmov/libc."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/mmx/cmov/libc"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/cmov/libc.so."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/mmx/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = 0
> SYS_open("/etc/ld.so.cache", 0, 00) = 3
> SYS_fstat64(3, 0xbfffefe8, 0x40016c40, 0x40016e60, 2) = 0
> SYS_mmap(0xbfffefc8, 0, 0x40016c40, 3, 0x40016d30) = 0x40018000
> SYS_close(3) = 0
> SYS_access(0x40012de4, 0, 0x40016c40, 0, 524288) = -2
> SYS_open("/lib/libc.so.6", 0, 027777775257) = 3
> SYS_read(3, "177ELF 01 01 01", 512) = 512
> SYS_fstat64(3, 0xbffff098, 0x40016c40, 0x40016e60, 0) = 0
> SYS_mmap(0xbfffef1c, 3, 0x40016c40, 0x132284, 0xbfffef50) = 0x40028000
> SYS_mmap(0xbfffef1c, 0x40028000, 0x40016c40, 0x128000, 0xbfffef68) =
> 0x40150000
> SYS_mmap(0xbfffef1c, 8836, 0x40016c40, 50, 0xbfffef68) = 0x40158000
> SYS_close(3) = 0
> SYS_munmap(0x40018000, 65341) = 0
> __libc_start_main(0x80496a0, 4, 0xbffff954, 0x8052610, 0x8052670
> <unfinished ...>
> setlocale(6, "") = "C"
> bindtextdomain("findutils", "/usr/share/locale" <unfinished ...>
> SYS_brk(NULL) = 0x80545b4
> SYS_brk(0x80755b4) = 0x80755b4
> SYS_brk(NULL) = 0x80755b4
> SYS_brk(0x8076000) = 0x8076000
> <... bindtextdomain resumed> ) = "/usr/share/locale"
> textdomain("findutils") = "findutils"
> time(NULL <unfinished ...>
> SYS_time(0, 0, 0x8052710, 0, 0xbffff954) = 0x41333a1b
> <... time resumed> ) = 1093876251
> getenv("FIND_BLOCK_SIZE") = NULL
> getenv("BLOCK_SIZE") = NULL
> getenv("POSIXLY_CORRECT") = NULL
> strchr("-!(),", '.') = NULL
> strchr("-!(),", '-') = "-!(),"
> malloc(56) = 0x8054638
> strchr("-!(),", '-') = "-!(),"
> strcmp("!", "name") = -77
> strcmp("not", "name") = 14
> strcmp("(", "name") = -70
> strcmp(")", "name") = -69
> strcmp(",", "name") = -66
> strcmp("a", "name") = -13
> strcmp("amin", "name") = -13
> strcmp("and", "name") = -13
> strcmp("anewer", "name") = -13
> strcmp("atime", "name") = -13
> strcmp("cmin", "name") = -11
> strcmp("cnewer", "name") = -11
> strcmp("ctime", "name") = -11
> strcmp("daystart", "name") = -10
> strcmp("depth", "name") = -10
> strcmp("empty", "name") = -9
> strcmp("exec", "name") = -9
> strcmp("false", "name") = -8
> strcmp("fls", "name") = -8
> strcmp("follow", "name") = -8
> strcmp("fprint", "name") = -8
> strcmp("fprint0", "name") = -8
> strcmp("fprintf", "name") = -8
> strcmp("fstype", "name") = -8
> strcmp("gid", "name") = -7
> strcmp("group", "name") = -7
> strcmp("help", "name") = -6
> strcmp("-help", "name") = -65
> strcmp("ilname", "name") = -5
> strcmp("iname", "name") = -5
> strcmp("inum", "name") = -5
> strcmp("ipath", "name") = -5
> strcmp("iregex", "name") = -5
> strcmp("links", "name") = -2
> strcmp("lname", "name") = -2
> strcmp("ls", "name") = -2
> strcmp("maxdepth", "name") = -1
> strcmp("mindepth", "name") = -1
> strcmp("mmin", "name") = -1
> strcmp("mount", "name") = -1
> strcmp("mtime", "name") = -1
> strcmp("name", "name") = 0
> malloc(56) = 0x8054678
> malloc(56) = 0x80546b8
> malloc(56) = 0x80546f8
> malloc(56) = 0x8054738
> malloc(56) = 0x8054778
> open64(".", 0, 01001242620 <unfinished ...>
> SYS_open(".", 32768, 00) = 3
> <... open64 resumed> ) = 3
> fchdir(3 <unfinished ...>
> SYS_fchdir(3, 32768, 4, 0xbffffabb, 0xbffff954) = 0
> <... fchdir resumed> ) = 0
> __lxstat64(3, ".", 0x8054500 <unfinished ...>
> SYS_lstat64(0x8052865, 0x8054500, 0x40157550, 0x4015a008, 0x8054500) = 0
> <... __lxstat64 resumed> ) = 0
> strchr("-!(),", '.') = NULL
> strlen(".") = 1
> __lxstat64(3, ".", 0xbffff850 <unfinished ...>
> SYS_lstat64(0xbffffab9, 0xbffff850, 0x40157550, 0x4015a008, 0xbffff850)
> = 0
> <... __lxstat64 resumed> ) = 0
> chdir("." <unfinished ...>
> SYS_chdir(0xbffffab9, 0xbffff850, 1, 0, 0xbffffab9) = 0
> <... chdir resumed> ) = 0
> __lxstat64(3, ".", 0xbffff7f0 <unfinished ...>
> SYS_lstat64(0x8052865, 0xbffff7f0, 0x40157550, 0x4015a008, 0xbffff7f0) =
> 0
> <... __lxstat64 resumed> ) = 0
> __lxstat64(3, ".", 0xbffff750 <unfinished ...>
> SYS_lstat64(0x8052865, 0xbffff750, 0x40157550, 0x4015a008, 0xbffff750) =
> 0
> <... __lxstat64 resumed> ) = 0
> realloc(NULL, 512) = 0x80547b8
> fnmatch("*.py", ".", 4) = 1
> strlen(".") = 1
> __errno_location() = 0x40157900
> opendir("." <unfinished ...>
> SYS_open("/dev/null", 67584, 010005272520) = -20
> SYS_open(".", 100352, 010005272520) = 4
> SYS_fstat64(4, 0xbffff54c, 0x40157550, 0x4015a008, 0xbffff54c) = 0
> SYS_fcntl64(4, 2, 1, 1, 0x40157550) = 0
> <... opendir resumed> ) = 0x80549c0
> malloc(512) = 0x80569f8
> __errno_location() = 0x40157900
> readdir(0x80549c0 <unfinished ...>
> SYS_getdents64(4, 0x80549f0, 8192, 0x40157900, 0x40157550) = 208
> SYS__llseek(4, 0, 0x6c2c6bd7, 0xbffff51c, 0) = 0
> <... readdir resumed> ) = 0x80549f0
> readdir(0x80549c0) = 0x8054a00
> readdir(0x80549c0) = 0x8054a10
> strlen("stuff.py~") = 9
> memcpy(0x80569f8, "stuff.py~", 10) = 0x80569f8
> readdir(0x80549c0) = 0x8054a28
> strlen("stuff.pyc") = 9
> memcpy(0x8056a02, "stuff.pyc", 10) = 0x8056a02
> readdir(0x80549c0) = 0x8054a40
> strlen("test.py") = 7
> memcpy(0x8056a0c, "test.py", 8) = 0x8056a0c
> readdir(0x80549c0) = 0x8054a58
> strlen("test.py~") = 8
> memcpy(0x8056a14, "test.py~", 9) = 0x8056a14
> readdir(0x80549c0 <unfinished ...>
> SYS_getdents64(4, 0x80549f0, 8192, 0x40157900, 0x40157550) = 32
> <... readdir resumed> ) = NULL
> __errno_location() = 0x40157900
> closedir(0x80549c0 <unfinished ...>
> SYS_close(4) = 0
> <... closedir resumed> ) = 0
> free(0x80569f8 <unfinished ...>
> SYS_brk(NULL) = 0x8076000
> SYS_brk(NULL) = 0x8076000
> SYS_brk(0x8075000) = 0x8075000
> SYS_brk(NULL) = 0x8075000
> <... free resumed> ) = <void>
> error(0, 75, 0x8053b72, 0xbffffab9, 0x4002fa10 <unfinished ...>
> SYS_write(2, "find: ", 6find: ) = 6
> SYS_write(2, ".", 1.) = 1
> SYS_write(2, ": Value too large for defined da"..., 39: Value too large
> for defined data type) = 39
> SYS_write(2, "n", 1
> ) = 1
> <... error resumed> ) = 0
> fchdir(3 <unfinished ...>
> SYS_fchdir(3, 0, 0, 0, 0xbffffab9) = 0
> <... fchdir resumed> ) = 0
> strchr("-!(),", '-') = "-!(),"
> exit(1 <unfinished ...>
> SYS_exit_group(1) = <void>
> SYS_exit(1 <unfinished ...>
> +++ exited (status 1) +++
> poppins[reida]:
-------------------------------------------------------
Date: Mon 04/05/2004 at 16:31 By: James Youngman <jay>
The likely difference between the two versions of find is that they use a different version of gnulib, and the updated version is now sensitive to this problem. Alternatively, maybe it's a glibc difference. Certainly the differences between the find application code is minimal.
Looking at the ltrace output, it looks like readdir() is failing. The likely bit of affected code is gnulib's savedir.c. That certainly should faiil if readdir() fails.
I suspect that somewhere in there is a filename whose base
name is more than 256 characters. To find out, please try this (on either the client or the server):
ls -R1 | awk '(length > 200) {print length, $0;}' | sort -n | tail
Try picking the last filename from the above and invoking find directly on it. The idea here is to pin things down to one path name that successfully reproduces the error.
Lastly, the output of "ltrace" isn't very helpful about the data that's returned from the system calls. What do you get if you use "strace"? What about "ltrace -S"?
CC List
-------
CC Address | Comment
------------------------------------+-----------------------------
timwaugh<twaugh --AT-- redhat --DOT-- com> | Handling similar bug for Red Hat.
241538 --AT-- bugs --DOT-- debian --DOT-- org | original report
andrewreid<andrew --DOT-- reid --AT-- nist --DOT-- gov> | Bug forwarded to upstream authors
File Attachments
-------------------
-------------------------------------------------------
Date: Mon 04/05/2004 at 15:29 Name: findbug.ltrace Size: 30.51KB By: ametzler
ltrace output
http://savannah.gnu.org/bugs/download.php?item_id=8455&item_file_id=1169
For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=8455>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Metzler <ametzler@debian.org>:
Bug#241538; Package findutils.
(full text, mbox, link).
Acknowledgement sent to James Youngman <noreply@savannah.gnu.org>:
Extra info received and forwarded to list. Copy sent to Andreas Metzler <ametzler@debian.org>.
(full text, mbox, link).
Message #37 received at 241538@bugs.debian.org (full text, mbox, reply):
This mail is an automated notification from the bugs tracker
of the project: findutils.
/**************************************************************************/
[bugs #8455] Latest Modifications:
Changes by:
James Youngman <jay@gnu.org>
'Date:
Sun 12/05/04 at 14:18 (GMT)
------------------ Additional Follow-up Comments ----------------------------
I have just read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=180065 which seems to state that the problem is in fact a Linux kernel bug for which a fix exists, and there is even a glibc workaround patch for it, too.
/**************************************************************************/
[bugs #8455] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8455>
Project: findutils
Submitted by: Andreas Metzler
On: Mon 04/05/04 at 15:29
Category: find
Severity: 5 - Average
Item Group: None
Resolution: None
Privacy: Public
Assigned to: None
Originator Name:
Originator Email:
Status: Open
Release: None
Fixed Release: None
Summary: anomaly on large xfs filesystems
Original Submission: This is a copy of <http://bugs.debian.org/241538>.
Andrew Reid writes:
--------------------------
Version: 4.1.20-3
I am having a rather strange difficulty with the "find" command.
For many paths on my system, including all paths in my
account, I get:
> # find <path> -print
> find: <path>: Value too large for defined data type
The failure occurs in some directories but not others, as described
below.
The set-up of the machine is such that user home directories can be
accessed by multiple routes from the start of the file system. I am
not certain that this is relevant, but describe it here for
completeness.
Users' actual home directories are divided into several numbered
"home" directories from the root, like this: /u/home<n>/<user>/
All user home directories are accessible via symlinks from
/u/users/<user> -> /u/home<n>/<user>
There is also a symlink at the root of the filesystem,
/users -> /u/users
The client is an x86 machine. The filesystems are remotely mounted
"xfs" file systems, mounted via NFS from an SGI file server. Each
home<n> subdirectory is separately mounted on the client by way of an
automounter. Most of these reside on separate disks on the server,
except for home1 and home2, which share a physical disk on the server.
The problem occurs for some of the /u/home<n>/ directories, but not
others.
All of these directories are exported identically (to each other) from
the file server, and imported identically by the client. There are
hardware differences between the mounted disks, which correlate with
the "find" problem -- home directories which occupy 48GB disks and use
more than 28GB of them seem to have this problem. The problem is also
common to all of the largest filesystems.
On a Debian "stable" client, importing the same file systems from the
same file server, running the same kernel, but using "find" from
version 4.1.7-2 of findutils, the problem does not occur.
On all systems, these calls work.
# find /u -maxdepth 1
# find /u/users -maxdepth 1
On the problem system in the problem directories, these calls:
# find /u/home<n> -maxdepth 1
fail with the "Value too large" error -- this path argument
is the direct path to the home directory.
Although the filesystem and automounter configuration on these
machines is not trivial, it is nevertheless identical between "stable"
and "testing" machines, and the "find" bug occurs only on the
"testing" machines. There is circumstantial evidence that the problem
involves large xfs filesystems.
--------------------------
He later provided me with the ltrace I am attaching.
thanks, cu andreas
Follow-up Comments
------------------
-------------------------------------------------------
Date: Sun 12/05/04 at 14:18 By: James Youngman <jay>
I have just read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=180065 which seems to state that the problem is in fact a Linux kernel bug for which a fix exists, and there is even a glibc workaround patch for it, too.
-------------------------------------------------------
Date: Thu 12/02/04 at 10:02 By: Tim Waugh <twaugh>
See also:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141167
-------------------------------------------------------
Date: Thu 12/02/04 at 09:11 By: James Youngman <jay>
See also http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141167
-------------------------------------------------------
Date: Mon 11/22/04 at 00:45 By: James Youngman <jay>
I've created a local XFS filesystem with a couple of million files in it (one directory has over 900,000 entries). find searches it in about 15 seconds without failing. I'm not using NFS though.
-------------------------------------------------------
Date: Sat 10/02/04 at 10:48 By: James Youngman <jay>
OK, having looked at the trace output, I still suspect that it is savedir() which is failing. I have a small number of questions.
1. If you use "tar" to copy the directory tree to a local filesystem, can you reproduce the problem? Don't forgert to use the "p" option when unpacking.
The other checks involve getting hold of a copy of the source. If you're not confident with compiling source code, don't worry about it. Otherwise, I have a couple of other suggested tests:
a) Change error() [in file error.c] so that it calls abort(). Then use GDB to get a stack backtrace from the coredump. Send me a copy of the stack backtrace. For the lower levels of the backtrace (say 3 as a guideline) show me which line that corresponds to (the will avoid problems caused by us looking at different versions of the code).
b) Use GDB to single-step through savedir() to figure out why it fails - if indeed (b) shows that it has failed.
Sorry to make you do all the work, but I can't reproduce the problem here.
-------------------------------------------------------
Date: Mon 08/30/04 at 15:54 By: 0 <None>
On Mon, Aug 09, 2004 at 01:01:12PM +0200, Andreas Metzler wrote:
> On 2004-04-01 Andrew Reid <Andrew.Reid@nist.gov> wrote:
> > Package: findutils
> > Version: 4.1.20-3
>
> > I am having a rather strange difficulty with the "find" command.
>
> > For many paths on my system, including all paths in my
> > account, I get:
>
> > > # find <path> -print
> > > find: <path>: Value too large for defined data type
> [...]
>
Thanks for the reply and sorry about my delay in replying -- partially
it's vacation season, and partially I've just been doing other stuff.
> While browsing upstream's bugtracker where I had forwarded the bug to
> I found this in
> http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=8455
>
> -----------------------
> The likely difference between the two versions of find is that they
> use a different version of gnulib, and the updated version is now
> sensitive to this problem. Alternatively, maybe it's a glibc
> difference. Certainly the differences between the find application
> code is minimal.
>
> Looking at the ltrace output, it looks like readdir() is failing. The
> likely bit of affected code is gnulib's savedir.c. That certainly
> should faiil if readdir() fails.
>
> I suspect that somewhere in there is a filename whose base name is
> more than 256 characters. To find out, please try this (on either the
> client or the server):
>
> ls -R1 | awk '(length > 200) {print length, $0;}' | sort -n | tail
This suspicion is not confirmed, alas -- the awk returns nothing
with length > 200. To check that it worked at all, I ratcheted
down the number, and I start to get lots of stuff once it's
less than around 50. Nothing longer than 100. I made no attempt
to refine it beyond that.
> Try picking the last filename from the above and invoking find
> directly on it. The idea here is to pin things down to one path name
> that successfully reproduces the error.
I appreciate the need for diagnosing under controlled conditions,
so I've picked a directory to run it, which I will use for future
tests, if any...
> Lastly, the output of "ltrace" isn't very helpful about the data
> that's returned from the system calls. What do you get if you use
> "strace"? What about "ltrace -S"?
Here's another crack at it -- in case you're curious, this was
test code for what, exactly, Python does to its internal search
paths at start-up time.
Also, recall that the filesystem being examined is an SGI XFS
filesystem which is NFS mounted by the Debian Sarge linux box
which is actually running the "find" command.
The directory:
> poppins[reida]: ls -al
> total 24
> drwxr-xr-x 2 reida user 95 Feb 3 2004 ./
> drwxr-xr-x 22 reida user 4096 Aug 25 20:35 ../
> -rw-r--r-- 1 reida user 20 Feb 3 2004 stuff.py
> -rw-r--r-- 1 reida user 229 Feb 3 2004 stuff.pyc
> -rw-r--r-- 1 reida user 44 Feb 3 2004 stuff.py~
> -rwxr-xr-- 1 reida user 230 Feb 3 2004 test.py*
> -rw-r--r-- 1 reida user 95 Feb 3 2004 test.py~
Debian Woody, with strace output afterwards.
> jeeves[reida]: find . -name "*.py"
> ./test.py
> ./stuff.py
> jeeves[reida]: strace find . -name "*.py"
> execve("/usr/bin/find", ["find", ".", "-name", "*.py"], [/* 35 vars */]) = 0
> uname({sys="Linux", node="jeeves", ...}) = 0
> brk(0) = 0x8053d54
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib", {st_mode=S_IFDIR|0755, st_size=776, ...}) = 0
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=41861, ...}) = 0
> old_mmap(NULL, 41861, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
> close(3) = 0
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "177ELF111 3 3 1 30222"..., 1024) = 1024
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1153784, ...}) = 0
> old_mmap(NULL, 1166560, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001f000
> mprotect(0x40132000, 40160, PROT_NONE) = 0
> old_mmap(0x40132000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x113000) = 0x40132000
> old_mmap(0x40138000, 15584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40138000
> close(3) = 0
> munmap(0x40014000, 41861) = 0
> brk(0) = 0x8053d54
> brk(0x8053d7c) = 0x8053d7c
> brk(0x8054000) = 0x8054000
> time(NULL) = 1093877075
> open(".", O_RDONLY|O_LARGEFILE) = 3
> fchdir(3) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> chdir(".") = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> brk(0x8055000) = 0x8055000
> open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> fstat64(4, {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> brk(0x8058000) = 0x8058000
> getdents64(0x4, 0x8054148, 0x2000, 0) = 208
> getdents64(0x4, 0x8054148, 0x2000, 0) = 0
> close(4) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
> write(1, "./test.pyn", 10./test.py) = 10
> write(1, "./stuff.pyn", 11./stuff.py) = 11
> fchdir(3) = 0
> munmap(0x40014000, 4096) = 0
> _exit(0) = ?
... then Debian Sarge: Since this is the system with the problem,
I have included both strace and ltrace -S output -- they seem to not
quite be the same, so you may of course use whichever is most useful
to you.
> poppins[reida]: find . -name "*.py"
> find: .: Value too large for defined data type
> poppins[reida]: strace find . -name "*.py"
> execve("/usr/bin/find", ["find", ".", "-name", "*.py"], [/* 46 vars */]) = 0
> uname({sys="Linux", node="poppins", ...}) = 0
> brk(0) = 0x80545b4
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib", {st_mode=S_IFDIR|0755, st_size=776, ...}) = 0
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=65341, ...}) = 0
> old_mmap(NULL, 65341, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
> close(3) = 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "177ELF111 3 3 1 200^1"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=1243856, ...}) = 0
> old_mmap(NULL, 1254020, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000
> old_mmap(0x40150000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x127000) = 0x40150000
> old_mmap(0x40158000, 8836, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40158000
> close(3) = 0
> munmap(0x40018000, 65341) = 0
> brk(0) = 0x80545b4
> brk(0x80755b4) = 0x80755b4
> brk(0) = 0x80755b4
> brk(0x8076000) = 0x8076000
> time(NULL) = 1093877299
> open(".", O_RDONLY|O_LARGEFILE) = 3
> fchdir(3) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> chdir(".") = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> fstat64(4, {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> getdents64(4, /* 219 entries */, 8192) = 8168
> _llseek(4, 2144606367, [2144606367], SEEK_SET) = 0
> getdents64(4, /* 144 entries */, 8192) = 5584
> close(4) = 0
> brk(0) = 0x8076000
> brk(0) = 0x8076000
> brk(0x8075000) = 0x8075000
> brk(0) = 0x8075000
> write(2, "find: ", 6find: ) = 6
> write(2, ".", 1.) = 1
> write(2, ": Value too large for defined da"..., 39: Value too large for defined data type) = 39
> write(2, "n", 1 ) = 1
> fchdir(3) = 0
> exit_group(1) = ?
> poppins[reida]: ltrace -S find . -name "*.py"
> SYS_uname(0xbffff70c) = 0
> SYS_brk(NULL) = 0x80545b4
> SYS_mmap(0xbffff4ec, 34, 0x40016c40, 4096, 565) = 0x40017000
> SYS_access(0x40012de4, 0, 0x40016c40, 0x40016e78, 24) = -2
> SYS_open("/etc/ld.so.preload", 0, 010000226744) = -2
> SYS_open("/usr/site/lib/tls/i686/mmx/cmov/"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/mmx/libc."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/cmov/libc"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/mmx/cmov/libc."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/mmx/cmov/libc"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/cmov/libc.so."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/mmx/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = 0
> SYS_open("/etc/ld.so.cache", 0, 00) = 3
> SYS_fstat64(3, 0xbfffefe8, 0x40016c40, 0x40016e60, 2) = 0
> SYS_mmap(0xbfffefc8, 0, 0x40016c40, 3, 0x40016d30) = 0x40018000
> SYS_close(3) = 0
> SYS_access(0x40012de4, 0, 0x40016c40, 0, 524288) = -2
> SYS_open("/lib/libc.so.6", 0, 027777775257) = 3
> SYS_read(3, "177ELF 01 01 01", 512) = 512
> SYS_fstat64(3, 0xbffff098, 0x40016c40, 0x40016e60, 0) = 0
> SYS_mmap(0xbfffef1c, 3, 0x40016c40, 0x132284, 0xbfffef50) = 0x40028000
> SYS_mmap(0xbfffef1c, 0x40028000, 0x40016c40, 0x128000, 0xbfffef68) =
> 0x40150000
> SYS_mmap(0xbfffef1c, 8836, 0x40016c40, 50, 0xbfffef68) = 0x40158000
> SYS_close(3) = 0
> SYS_munmap(0x40018000, 65341) = 0
> __libc_start_main(0x80496a0, 4, 0xbffff954, 0x8052610, 0x8052670
> <unfinished ...>
> setlocale(6, "") = "C"
> bindtextdomain("findutils", "/usr/share/locale" <unfinished ...>
> SYS_brk(NULL) = 0x80545b4
> SYS_brk(0x80755b4) = 0x80755b4
> SYS_brk(NULL) = 0x80755b4
> SYS_brk(0x8076000) = 0x8076000
> <... bindtextdomain resumed> ) = "/usr/share/locale"
> textdomain("findutils") = "findutils"
> time(NULL <unfinished ...>
> SYS_time(0, 0, 0x8052710, 0, 0xbffff954) = 0x41333a1b
> <... time resumed> ) = 1093876251
> getenv("FIND_BLOCK_SIZE") = NULL
> getenv("BLOCK_SIZE") = NULL
> getenv("POSIXLY_CORRECT") = NULL
> strchr("-!(),", '.') = NULL
> strchr("-!(),", '-') = "-!(),"
> malloc(56) = 0x8054638
> strchr("-!(),", '-') = "-!(),"
> strcmp("!", "name") = -77
> strcmp("not", "name") = 14
> strcmp("(", "name") = -70
> strcmp(")", "name") = -69
> strcmp(",", "name") = -66
> strcmp("a", "name") = -13
> strcmp("amin", "name") = -13
> strcmp("and", "name") = -13
> strcmp("anewer", "name") = -13
> strcmp("atime", "name") = -13
> strcmp("cmin", "name") = -11
> strcmp("cnewer", "name") = -11
> strcmp("ctime", "name") = -11
> strcmp("daystart", "name") = -10
> strcmp("depth", "name") = -10
> strcmp("empty", "name") = -9
> strcmp("exec", "name") = -9
> strcmp("false", "name") = -8
> strcmp("fls", "name") = -8
> strcmp("follow", "name") = -8
> strcmp("fprint", "name") = -8
> strcmp("fprint0", "name") = -8
> strcmp("fprintf", "name") = -8
> strcmp("fstype", "name") = -8
> strcmp("gid", "name") = -7
> strcmp("group", "name") = -7
> strcmp("help", "name") = -6
> strcmp("-help", "name") = -65
> strcmp("ilname", "name") = -5
> strcmp("iname", "name") = -5
> strcmp("inum", "name") = -5
> strcmp("ipath", "name") = -5
> strcmp("iregex", "name") = -5
> strcmp("links", "name") = -2
> strcmp("lname", "name") = -2
> strcmp("ls", "name") = -2
> strcmp("maxdepth", "name") = -1
> strcmp("mindepth", "name") = -1
> strcmp("mmin", "name") = -1
> strcmp("mount", "name") = -1
> strcmp("mtime", "name") = -1
> strcmp("name", "name") = 0
> malloc(56) = 0x8054678
> malloc(56) = 0x80546b8
> malloc(56) = 0x80546f8
> malloc(56) = 0x8054738
> malloc(56) = 0x8054778
> open64(".", 0, 01001242620 <unfinished ...>
> SYS_open(".", 32768, 00) = 3
> <... open64 resumed> ) = 3
> fchdir(3 <unfinished ...>
> SYS_fchdir(3, 32768, 4, 0xbffffabb, 0xbffff954) = 0
> <... fchdir resumed> ) = 0
> __lxstat64(3, ".", 0x8054500 <unfinished ...>
> SYS_lstat64(0x8052865, 0x8054500, 0x40157550, 0x4015a008, 0x8054500) = 0
> <... __lxstat64 resumed> ) = 0
> strchr("-!(),", '.') = NULL
> strlen(".") = 1
> __lxstat64(3, ".", 0xbffff850 <unfinished ...>
> SYS_lstat64(0xbffffab9, 0xbffff850, 0x40157550, 0x4015a008, 0xbffff850)
> = 0
> <... __lxstat64 resumed> ) = 0
> chdir("." <unfinished ...>
> SYS_chdir(0xbffffab9, 0xbffff850, 1, 0, 0xbffffab9) = 0
> <... chdir resumed> ) = 0
> __lxstat64(3, ".", 0xbffff7f0 <unfinished ...>
> SYS_lstat64(0x8052865, 0xbffff7f0, 0x40157550, 0x4015a008, 0xbffff7f0) =
> 0
> <... __lxstat64 resumed> ) = 0
> __lxstat64(3, ".", 0xbffff750 <unfinished ...>
> SYS_lstat64(0x8052865, 0xbffff750, 0x40157550, 0x4015a008, 0xbffff750) =
> 0
> <... __lxstat64 resumed> ) = 0
> realloc(NULL, 512) = 0x80547b8
> fnmatch("*.py", ".", 4) = 1
> strlen(".") = 1
> __errno_location() = 0x40157900
> opendir("." <unfinished ...>
> SYS_open("/dev/null", 67584, 010005272520) = -20
> SYS_open(".", 100352, 010005272520) = 4
> SYS_fstat64(4, 0xbffff54c, 0x40157550, 0x4015a008, 0xbffff54c) = 0
> SYS_fcntl64(4, 2, 1, 1, 0x40157550) = 0
> <... opendir resumed> ) = 0x80549c0
> malloc(512) = 0x80569f8
> __errno_location() = 0x40157900
> readdir(0x80549c0 <unfinished ...>
> SYS_getdents64(4, 0x80549f0, 8192, 0x40157900, 0x40157550) = 208
> SYS__llseek(4, 0, 0x6c2c6bd7, 0xbffff51c, 0) = 0
> <... readdir resumed> ) = 0x80549f0
> readdir(0x80549c0) = 0x8054a00
> readdir(0x80549c0) = 0x8054a10
> strlen("stuff.py~") = 9
> memcpy(0x80569f8, "stuff.py~", 10) = 0x80569f8
> readdir(0x80549c0) = 0x8054a28
> strlen("stuff.pyc") = 9
> memcpy(0x8056a02, "stuff.pyc", 10) = 0x8056a02
> readdir(0x80549c0) = 0x8054a40
> strlen("test.py") = 7
> memcpy(0x8056a0c, "test.py", 8) = 0x8056a0c
> readdir(0x80549c0) = 0x8054a58
> strlen("test.py~") = 8
> memcpy(0x8056a14, "test.py~", 9) = 0x8056a14
> readdir(0x80549c0 <unfinished ...>
> SYS_getdents64(4, 0x80549f0, 8192, 0x40157900, 0x40157550) = 32
> <... readdir resumed> ) = NULL
> __errno_location() = 0x40157900
> closedir(0x80549c0 <unfinished ...>
> SYS_close(4) = 0
> <... closedir resumed> ) = 0
> free(0x80569f8 <unfinished ...>
> SYS_brk(NULL) = 0x8076000
> SYS_brk(NULL) = 0x8076000
> SYS_brk(0x8075000) = 0x8075000
> SYS_brk(NULL) = 0x8075000
> <... free resumed> ) = <void>
> error(0, 75, 0x8053b72, 0xbffffab9, 0x4002fa10 <unfinished ...>
> SYS_write(2, "find: ", 6find: ) = 6
> SYS_write(2, ".", 1.) = 1
> SYS_write(2, ": Value too large for defined da"..., 39: Value too large
> for defined data type) = 39
> SYS_write(2, "n", 1
> ) = 1
> <... error resumed> ) = 0
> fchdir(3 <unfinished ...>
> SYS_fchdir(3, 0, 0, 0, 0xbffffab9) = 0
> <... fchdir resumed> ) = 0
> strchr("-!(),", '-') = "-!(),"
> exit(1 <unfinished ...>
> SYS_exit_group(1) = <void>
> SYS_exit(1 <unfinished ...>
> +++ exited (status 1) +++
> poppins[reida]:
-------------------------------------------------------
Date: Mon 04/05/04 at 16:31 By: James Youngman <jay>
The likely difference between the two versions of find is that they use a different version of gnulib, and the updated version is now sensitive to this problem. Alternatively, maybe it's a glibc difference. Certainly the differences between the find application code is minimal.
Looking at the ltrace output, it looks like readdir() is failing. The likely bit of affected code is gnulib's savedir.c. That certainly should faiil if readdir() fails.
I suspect that somewhere in there is a filename whose base
name is more than 256 characters. To find out, please try this (on either the client or the server):
ls -R1 | awk '(length > 200) {print length, $0;}' | sort -n | tail
Try picking the last filename from the above and invoking find directly on it. The idea here is to pin things down to one path name that successfully reproduces the error.
Lastly, the output of "ltrace" isn't very helpful about the data that's returned from the system calls. What do you get if you use "strace"? What about "ltrace -S"?
CC List
-------
CC Address | Comment
------------------------------------+-----------------------------
timwaugh<twaugh --AT-- redhat --DOT-- com> | Handling similar bug for Red Hat.
241538 --AT-- bugs --DOT-- debian --DOT-- org | original report
andrewreid<andrew --DOT-- reid --AT-- nist --DOT-- gov> | Bug forwarded to upstream authors
File Attachments
-------------------
-------------------------------------------------------
Date: Mon 04/05/04 at 15:29 Name: findbug.ltrace Size: 30.51KB By: ametzler
ltrace output
http://savannah.gnu.org/bugs/download.php?item_id=8455&item_file_id=1169
For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=8455>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Metzler <ametzler@debian.org>:
Bug#241538; Package findutils.
(full text, mbox, link).
Acknowledgement sent to James Youngman <noreply@savannah.gnu.org>:
Extra info received and forwarded to list. Copy sent to Andreas Metzler <ametzler@debian.org>.
(full text, mbox, link).
Message #42 received at 241538@bugs.debian.org (full text, mbox, reply):
This mail is an automated notification from the bugs tracker
of the project: findutils.
/**************************************************************************/
[bugs #8455] Latest Modifications:
Changes by:
James Youngman <jay@gnu.org>
'Date:
Sun 12/05/04 at 14:41 (GMT)
------------------ Additional Follow-up Comments ----------------------------
Hmm. See also http://seclists.org/lists/linux-kernel/2000/May/5068.html.
The IRIX documentation for exports(4) says:
32bitclients
Causes the server to mask off the high order 32 bits of directory cookies in NFS version 3 directory operations. This option may be required when clients run 32-bit operating systems that assume the entire cookie is contained in 32 bits and reject responses containing version 3 cookies with high bits on. IRIX 5.3 and Solaris 2.5 are examples of 32-bit operating systems with this behavior, which produces error messages like "Cannot decode response" on directory operations. XFS filesystems on the server can generate cookies with high bits on. Exporting filesystems with the 32bitclients option causes these bits to be masked and prevents error messages.
/**************************************************************************/
[bugs #8455] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8455>
Project: findutils
Submitted by: Andreas Metzler
On: Mon 04/05/04 at 15:29
Category: find
Severity: 5 - Average
Item Group: None
Resolution: None
Privacy: Public
Assigned to: None
Originator Name:
Originator Email:
Status: Open
Release: None
Fixed Release: None
Summary: anomaly on large xfs filesystems
Original Submission: This is a copy of <http://bugs.debian.org/241538>.
Andrew Reid writes:
--------------------------
Version: 4.1.20-3
I am having a rather strange difficulty with the "find" command.
For many paths on my system, including all paths in my
account, I get:
> # find <path> -print
> find: <path>: Value too large for defined data type
The failure occurs in some directories but not others, as described
below.
The set-up of the machine is such that user home directories can be
accessed by multiple routes from the start of the file system. I am
not certain that this is relevant, but describe it here for
completeness.
Users' actual home directories are divided into several numbered
"home" directories from the root, like this: /u/home<n>/<user>/
All user home directories are accessible via symlinks from
/u/users/<user> -> /u/home<n>/<user>
There is also a symlink at the root of the filesystem,
/users -> /u/users
The client is an x86 machine. The filesystems are remotely mounted
"xfs" file systems, mounted via NFS from an SGI file server. Each
home<n> subdirectory is separately mounted on the client by way of an
automounter. Most of these reside on separate disks on the server,
except for home1 and home2, which share a physical disk on the server.
The problem occurs for some of the /u/home<n>/ directories, but not
others.
All of these directories are exported identically (to each other) from
the file server, and imported identically by the client. There are
hardware differences between the mounted disks, which correlate with
the "find" problem -- home directories which occupy 48GB disks and use
more than 28GB of them seem to have this problem. The problem is also
common to all of the largest filesystems.
On a Debian "stable" client, importing the same file systems from the
same file server, running the same kernel, but using "find" from
version 4.1.7-2 of findutils, the problem does not occur.
On all systems, these calls work.
# find /u -maxdepth 1
# find /u/users -maxdepth 1
On the problem system in the problem directories, these calls:
# find /u/home<n> -maxdepth 1
fail with the "Value too large" error -- this path argument
is the direct path to the home directory.
Although the filesystem and automounter configuration on these
machines is not trivial, it is nevertheless identical between "stable"
and "testing" machines, and the "find" bug occurs only on the
"testing" machines. There is circumstantial evidence that the problem
involves large xfs filesystems.
--------------------------
He later provided me with the ltrace I am attaching.
thanks, cu andreas
Follow-up Comments
------------------
-------------------------------------------------------
Date: Sun 12/05/04 at 14:41 By: James Youngman <jay>
Hmm. See also http://seclists.org/lists/linux-kernel/2000/May/5068.html.
The IRIX documentation for exports(4) says:
32bitclients
Causes the server to mask off the high order 32 bits of directory cookies in NFS version 3 directory operations. This option may be required when clients run 32-bit operating systems that assume the entire cookie is contained in 32 bits and reject responses containing version 3 cookies with high bits on. IRIX 5.3 and Solaris 2.5 are examples of 32-bit operating systems with this behavior, which produces error messages like "Cannot decode response" on directory operations. XFS filesystems on the server can generate cookies with high bits on. Exporting filesystems with the 32bitclients option causes these bits to be masked and prevents error messages.
-------------------------------------------------------
Date: Sun 12/05/04 at 14:18 By: James Youngman <jay>
I have just read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=180065 which seems to state that the problem is in fact a Linux kernel bug for which a fix exists, and there is even a glibc workaround patch for it, too.
-------------------------------------------------------
Date: Thu 12/02/04 at 10:02 By: Tim Waugh <twaugh>
See also:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141167
-------------------------------------------------------
Date: Thu 12/02/04 at 09:11 By: James Youngman <jay>
See also http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141167
-------------------------------------------------------
Date: Mon 11/22/04 at 00:45 By: James Youngman <jay>
I've created a local XFS filesystem with a couple of million files in it (one directory has over 900,000 entries). find searches it in about 15 seconds without failing. I'm not using NFS though.
-------------------------------------------------------
Date: Sat 10/02/04 at 10:48 By: James Youngman <jay>
OK, having looked at the trace output, I still suspect that it is savedir() which is failing. I have a small number of questions.
1. If you use "tar" to copy the directory tree to a local filesystem, can you reproduce the problem? Don't forgert to use the "p" option when unpacking.
The other checks involve getting hold of a copy of the source. If you're not confident with compiling source code, don't worry about it. Otherwise, I have a couple of other suggested tests:
a) Change error() [in file error.c] so that it calls abort(). Then use GDB to get a stack backtrace from the coredump. Send me a copy of the stack backtrace. For the lower levels of the backtrace (say 3 as a guideline) show me which line that corresponds to (the will avoid problems caused by us looking at different versions of the code).
b) Use GDB to single-step through savedir() to figure out why it fails - if indeed (b) shows that it has failed.
Sorry to make you do all the work, but I can't reproduce the problem here.
-------------------------------------------------------
Date: Mon 08/30/04 at 15:54 By: 0 <None>
On Mon, Aug 09, 2004 at 01:01:12PM +0200, Andreas Metzler wrote:
> On 2004-04-01 Andrew Reid <Andrew.Reid@nist.gov> wrote:
> > Package: findutils
> > Version: 4.1.20-3
>
> > I am having a rather strange difficulty with the "find" command.
>
> > For many paths on my system, including all paths in my
> > account, I get:
>
> > > # find <path> -print
> > > find: <path>: Value too large for defined data type
> [...]
>
Thanks for the reply and sorry about my delay in replying -- partially
it's vacation season, and partially I've just been doing other stuff.
> While browsing upstream's bugtracker where I had forwarded the bug to
> I found this in
> http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=8455
>
> -----------------------
> The likely difference between the two versions of find is that they
> use a different version of gnulib, and the updated version is now
> sensitive to this problem. Alternatively, maybe it's a glibc
> difference. Certainly the differences between the find application
> code is minimal.
>
> Looking at the ltrace output, it looks like readdir() is failing. The
> likely bit of affected code is gnulib's savedir.c. That certainly
> should faiil if readdir() fails.
>
> I suspect that somewhere in there is a filename whose base name is
> more than 256 characters. To find out, please try this (on either the
> client or the server):
>
> ls -R1 | awk '(length > 200) {print length, $0;}' | sort -n | tail
This suspicion is not confirmed, alas -- the awk returns nothing
with length > 200. To check that it worked at all, I ratcheted
down the number, and I start to get lots of stuff once it's
less than around 50. Nothing longer than 100. I made no attempt
to refine it beyond that.
> Try picking the last filename from the above and invoking find
> directly on it. The idea here is to pin things down to one path name
> that successfully reproduces the error.
I appreciate the need for diagnosing under controlled conditions,
so I've picked a directory to run it, which I will use for future
tests, if any...
> Lastly, the output of "ltrace" isn't very helpful about the data
> that's returned from the system calls. What do you get if you use
> "strace"? What about "ltrace -S"?
Here's another crack at it -- in case you're curious, this was
test code for what, exactly, Python does to its internal search
paths at start-up time.
Also, recall that the filesystem being examined is an SGI XFS
filesystem which is NFS mounted by the Debian Sarge linux box
which is actually running the "find" command.
The directory:
> poppins[reida]: ls -al
> total 24
> drwxr-xr-x 2 reida user 95 Feb 3 2004 ./
> drwxr-xr-x 22 reida user 4096 Aug 25 20:35 ../
> -rw-r--r-- 1 reida user 20 Feb 3 2004 stuff.py
> -rw-r--r-- 1 reida user 229 Feb 3 2004 stuff.pyc
> -rw-r--r-- 1 reida user 44 Feb 3 2004 stuff.py~
> -rwxr-xr-- 1 reida user 230 Feb 3 2004 test.py*
> -rw-r--r-- 1 reida user 95 Feb 3 2004 test.py~
Debian Woody, with strace output afterwards.
> jeeves[reida]: find . -name "*.py"
> ./test.py
> ./stuff.py
> jeeves[reida]: strace find . -name "*.py"
> execve("/usr/bin/find", ["find", ".", "-name", "*.py"], [/* 35 vars */]) = 0
> uname({sys="Linux", node="jeeves", ...}) = 0
> brk(0) = 0x8053d54
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib", {st_mode=S_IFDIR|0755, st_size=776, ...}) = 0
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=41861, ...}) = 0
> old_mmap(NULL, 41861, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
> close(3) = 0
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "177ELF111 3 3 1 30222"..., 1024) = 1024
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1153784, ...}) = 0
> old_mmap(NULL, 1166560, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001f000
> mprotect(0x40132000, 40160, PROT_NONE) = 0
> old_mmap(0x40132000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x113000) = 0x40132000
> old_mmap(0x40138000, 15584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40138000
> close(3) = 0
> munmap(0x40014000, 41861) = 0
> brk(0) = 0x8053d54
> brk(0x8053d7c) = 0x8053d7c
> brk(0x8054000) = 0x8054000
> time(NULL) = 1093877075
> open(".", O_RDONLY|O_LARGEFILE) = 3
> fchdir(3) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> chdir(".") = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> brk(0x8055000) = 0x8055000
> open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> fstat64(4, {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> brk(0x8058000) = 0x8058000
> getdents64(0x4, 0x8054148, 0x2000, 0) = 208
> getdents64(0x4, 0x8054148, 0x2000, 0) = 0
> close(4) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
> write(1, "./test.pyn", 10./test.py) = 10
> write(1, "./stuff.pyn", 11./stuff.py) = 11
> fchdir(3) = 0
> munmap(0x40014000, 4096) = 0
> _exit(0) = ?
... then Debian Sarge: Since this is the system with the problem,
I have included both strace and ltrace -S output -- they seem to not
quite be the same, so you may of course use whichever is most useful
to you.
> poppins[reida]: find . -name "*.py"
> find: .: Value too large for defined data type
> poppins[reida]: strace find . -name "*.py"
> execve("/usr/bin/find", ["find", ".", "-name", "*.py"], [/* 46 vars */]) = 0
> uname({sys="Linux", node="poppins", ...}) = 0
> brk(0) = 0x80545b4
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib", {st_mode=S_IFDIR|0755, st_size=776, ...}) = 0
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=65341, ...}) = 0
> old_mmap(NULL, 65341, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
> close(3) = 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "177ELF111 3 3 1 200^1"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=1243856, ...}) = 0
> old_mmap(NULL, 1254020, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000
> old_mmap(0x40150000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x127000) = 0x40150000
> old_mmap(0x40158000, 8836, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40158000
> close(3) = 0
> munmap(0x40018000, 65341) = 0
> brk(0) = 0x80545b4
> brk(0x80755b4) = 0x80755b4
> brk(0) = 0x80755b4
> brk(0x8076000) = 0x8076000
> time(NULL) = 1093877299
> open(".", O_RDONLY|O_LARGEFILE) = 3
> fchdir(3) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> chdir(".") = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> fstat64(4, {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> getdents64(4, /* 219 entries */, 8192) = 8168
> _llseek(4, 2144606367, [2144606367], SEEK_SET) = 0
> getdents64(4, /* 144 entries */, 8192) = 5584
> close(4) = 0
> brk(0) = 0x8076000
> brk(0) = 0x8076000
> brk(0x8075000) = 0x8075000
> brk(0) = 0x8075000
> write(2, "find: ", 6find: ) = 6
> write(2, ".", 1.) = 1
> write(2, ": Value too large for defined da"..., 39: Value too large for defined data type) = 39
> write(2, "n", 1 ) = 1
> fchdir(3) = 0
> exit_group(1) = ?
> poppins[reida]: ltrace -S find . -name "*.py"
> SYS_uname(0xbffff70c) = 0
> SYS_brk(NULL) = 0x80545b4
> SYS_mmap(0xbffff4ec, 34, 0x40016c40, 4096, 565) = 0x40017000
> SYS_access(0x40012de4, 0, 0x40016c40, 0x40016e78, 24) = -2
> SYS_open("/etc/ld.so.preload", 0, 010000226744) = -2
> SYS_open("/usr/site/lib/tls/i686/mmx/cmov/"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/mmx/libc."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/cmov/libc"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/mmx/cmov/libc."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/mmx/cmov/libc"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/cmov/libc.so."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/mmx/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = 0
> SYS_open("/etc/ld.so.cache", 0, 00) = 3
> SYS_fstat64(3, 0xbfffefe8, 0x40016c40, 0x40016e60, 2) = 0
> SYS_mmap(0xbfffefc8, 0, 0x40016c40, 3, 0x40016d30) = 0x40018000
> SYS_close(3) = 0
> SYS_access(0x40012de4, 0, 0x40016c40, 0, 524288) = -2
> SYS_open("/lib/libc.so.6", 0, 027777775257) = 3
> SYS_read(3, "177ELF 01 01 01", 512) = 512
> SYS_fstat64(3, 0xbffff098, 0x40016c40, 0x40016e60, 0) = 0
> SYS_mmap(0xbfffef1c, 3, 0x40016c40, 0x132284, 0xbfffef50) = 0x40028000
> SYS_mmap(0xbfffef1c, 0x40028000, 0x40016c40, 0x128000, 0xbfffef68) =
> 0x40150000
> SYS_mmap(0xbfffef1c, 8836, 0x40016c40, 50, 0xbfffef68) = 0x40158000
> SYS_close(3) = 0
> SYS_munmap(0x40018000, 65341) = 0
> __libc_start_main(0x80496a0, 4, 0xbffff954, 0x8052610, 0x8052670
> <unfinished ...>
> setlocale(6, "") = "C"
> bindtextdomain("findutils", "/usr/share/locale" <unfinished ...>
> SYS_brk(NULL) = 0x80545b4
> SYS_brk(0x80755b4) = 0x80755b4
> SYS_brk(NULL) = 0x80755b4
> SYS_brk(0x8076000) = 0x8076000
> <... bindtextdomain resumed> ) = "/usr/share/locale"
> textdomain("findutils") = "findutils"
> time(NULL <unfinished ...>
> SYS_time(0, 0, 0x8052710, 0, 0xbffff954) = 0x41333a1b
> <... time resumed> ) = 1093876251
> getenv("FIND_BLOCK_SIZE") = NULL
> getenv("BLOCK_SIZE") = NULL
> getenv("POSIXLY_CORRECT") = NULL
> strchr("-!(),", '.') = NULL
> strchr("-!(),", '-') = "-!(),"
> malloc(56) = 0x8054638
> strchr("-!(),", '-') = "-!(),"
> strcmp("!", "name") = -77
> strcmp("not", "name") = 14
> strcmp("(", "name") = -70
> strcmp(")", "name") = -69
> strcmp(",", "name") = -66
> strcmp("a", "name") = -13
> strcmp("amin", "name") = -13
> strcmp("and", "name") = -13
> strcmp("anewer", "name") = -13
> strcmp("atime", "name") = -13
> strcmp("cmin", "name") = -11
> strcmp("cnewer", "name") = -11
> strcmp("ctime", "name") = -11
> strcmp("daystart", "name") = -10
> strcmp("depth", "name") = -10
> strcmp("empty", "name") = -9
> strcmp("exec", "name") = -9
> strcmp("false", "name") = -8
> strcmp("fls", "name") = -8
> strcmp("follow", "name") = -8
> strcmp("fprint", "name") = -8
> strcmp("fprint0", "name") = -8
> strcmp("fprintf", "name") = -8
> strcmp("fstype", "name") = -8
> strcmp("gid", "name") = -7
> strcmp("group", "name") = -7
> strcmp("help", "name") = -6
> strcmp("-help", "name") = -65
> strcmp("ilname", "name") = -5
> strcmp("iname", "name") = -5
> strcmp("inum", "name") = -5
> strcmp("ipath", "name") = -5
> strcmp("iregex", "name") = -5
> strcmp("links", "name") = -2
> strcmp("lname", "name") = -2
> strcmp("ls", "name") = -2
> strcmp("maxdepth", "name") = -1
> strcmp("mindepth", "name") = -1
> strcmp("mmin", "name") = -1
> strcmp("mount", "name") = -1
> strcmp("mtime", "name") = -1
> strcmp("name", "name") = 0
> malloc(56) = 0x8054678
> malloc(56) = 0x80546b8
> malloc(56) = 0x80546f8
> malloc(56) = 0x8054738
> malloc(56) = 0x8054778
> open64(".", 0, 01001242620 <unfinished ...>
> SYS_open(".", 32768, 00) = 3
> <... open64 resumed> ) = 3
> fchdir(3 <unfinished ...>
> SYS_fchdir(3, 32768, 4, 0xbffffabb, 0xbffff954) = 0
> <... fchdir resumed> ) = 0
> __lxstat64(3, ".", 0x8054500 <unfinished ...>
> SYS_lstat64(0x8052865, 0x8054500, 0x40157550, 0x4015a008, 0x8054500) = 0
> <... __lxstat64 resumed> ) = 0
> strchr("-!(),", '.') = NULL
> strlen(".") = 1
> __lxstat64(3, ".", 0xbffff850 <unfinished ...>
> SYS_lstat64(0xbffffab9, 0xbffff850, 0x40157550, 0x4015a008, 0xbffff850)
> = 0
> <... __lxstat64 resumed> ) = 0
> chdir("." <unfinished ...>
> SYS_chdir(0xbffffab9, 0xbffff850, 1, 0, 0xbffffab9) = 0
> <... chdir resumed> ) = 0
> __lxstat64(3, ".", 0xbffff7f0 <unfinished ...>
> SYS_lstat64(0x8052865, 0xbffff7f0, 0x40157550, 0x4015a008, 0xbffff7f0) =
> 0
> <... __lxstat64 resumed> ) = 0
> __lxstat64(3, ".", 0xbffff750 <unfinished ...>
> SYS_lstat64(0x8052865, 0xbffff750, 0x40157550, 0x4015a008, 0xbffff750) =
> 0
> <... __lxstat64 resumed> ) = 0
> realloc(NULL, 512) = 0x80547b8
> fnmatch("*.py", ".", 4) = 1
> strlen(".") = 1
> __errno_location() = 0x40157900
> opendir("." <unfinished ...>
> SYS_open("/dev/null", 67584, 010005272520) = -20
> SYS_open(".", 100352, 010005272520) = 4
> SYS_fstat64(4, 0xbffff54c, 0x40157550, 0x4015a008, 0xbffff54c) = 0
> SYS_fcntl64(4, 2, 1, 1, 0x40157550) = 0
> <... opendir resumed> ) = 0x80549c0
> malloc(512) = 0x80569f8
> __errno_location() = 0x40157900
> readdir(0x80549c0 <unfinished ...>
> SYS_getdents64(4, 0x80549f0, 8192, 0x40157900, 0x40157550) = 208
> SYS__llseek(4, 0, 0x6c2c6bd7, 0xbffff51c, 0) = 0
> <... readdir resumed> ) = 0x80549f0
> readdir(0x80549c0) = 0x8054a00
> readdir(0x80549c0) = 0x8054a10
> strlen("stuff.py~") = 9
> memcpy(0x80569f8, "stuff.py~", 10) = 0x80569f8
> readdir(0x80549c0) = 0x8054a28
> strlen("stuff.pyc") = 9
> memcpy(0x8056a02, "stuff.pyc", 10) = 0x8056a02
> readdir(0x80549c0) = 0x8054a40
> strlen("test.py") = 7
> memcpy(0x8056a0c, "test.py", 8) = 0x8056a0c
> readdir(0x80549c0) = 0x8054a58
> strlen("test.py~") = 8
> memcpy(0x8056a14, "test.py~", 9) = 0x8056a14
> readdir(0x80549c0 <unfinished ...>
> SYS_getdents64(4, 0x80549f0, 8192, 0x40157900, 0x40157550) = 32
> <... readdir resumed> ) = NULL
> __errno_location() = 0x40157900
> closedir(0x80549c0 <unfinished ...>
> SYS_close(4) = 0
> <... closedir resumed> ) = 0
> free(0x80569f8 <unfinished ...>
> SYS_brk(NULL) = 0x8076000
> SYS_brk(NULL) = 0x8076000
> SYS_brk(0x8075000) = 0x8075000
> SYS_brk(NULL) = 0x8075000
> <... free resumed> ) = <void>
> error(0, 75, 0x8053b72, 0xbffffab9, 0x4002fa10 <unfinished ...>
> SYS_write(2, "find: ", 6find: ) = 6
> SYS_write(2, ".", 1.) = 1
> SYS_write(2, ": Value too large for defined da"..., 39: Value too large
> for defined data type) = 39
> SYS_write(2, "n", 1
> ) = 1
> <... error resumed> ) = 0
> fchdir(3 <unfinished ...>
> SYS_fchdir(3, 0, 0, 0, 0xbffffab9) = 0
> <... fchdir resumed> ) = 0
> strchr("-!(),", '-') = "-!(),"
> exit(1 <unfinished ...>
> SYS_exit_group(1) = <void>
> SYS_exit(1 <unfinished ...>
> +++ exited (status 1) +++
> poppins[reida]:
-------------------------------------------------------
Date: Mon 04/05/04 at 16:31 By: James Youngman <jay>
The likely difference between the two versions of find is that they use a different version of gnulib, and the updated version is now sensitive to this problem. Alternatively, maybe it's a glibc difference. Certainly the differences between the find application code is minimal.
Looking at the ltrace output, it looks like readdir() is failing. The likely bit of affected code is gnulib's savedir.c. That certainly should faiil if readdir() fails.
I suspect that somewhere in there is a filename whose base
name is more than 256 characters. To find out, please try this (on either the client or the server):
ls -R1 | awk '(length > 200) {print length, $0;}' | sort -n | tail
Try picking the last filename from the above and invoking find directly on it. The idea here is to pin things down to one path name that successfully reproduces the error.
Lastly, the output of "ltrace" isn't very helpful about the data that's returned from the system calls. What do you get if you use "strace"? What about "ltrace -S"?
CC List
-------
CC Address | Comment
------------------------------------+-----------------------------
timwaugh<twaugh --AT-- redhat --DOT-- com> | Handling similar bug for Red Hat.
241538 --AT-- bugs --DOT-- debian --DOT-- org | original report
andrewreid<andrew --DOT-- reid --AT-- nist --DOT-- gov> | Bug forwarded to upstream authors
File Attachments
-------------------
-------------------------------------------------------
Date: Mon 04/05/04 at 15:29 Name: findbug.ltrace Size: 30.51KB By: ametzler
ltrace output
http://savannah.gnu.org/bugs/download.php?item_id=8455&item_file_id=1169
For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=8455>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Metzler <ametzler@debian.org>:
Bug#241538; Package findutils.
(full text, mbox, link).
Acknowledgement sent to James Youngman <noreply@savannah.gnu.org>:
Extra info received and forwarded to list. Copy sent to Andreas Metzler <ametzler@debian.org>.
(full text, mbox, link).
Message #47 received at 241538@bugs.debian.org (full text, mbox, reply):
This mail is an automated notification from the bugs tracker
of the project: findutils.
/**************************************************************************/
[bugs #8455] Latest Modifications:
Changes by:
James Youngman <jay@gnu.org>
'Date:
Sun 12/05/04 at 14:46 (GMT)
What | Removed | Added
---------------------------------------------------------------------------
Resolution | None | Invalid
Assigned to | None | jay
------------------ Additional Follow-up Comments ----------------------------
Hence I don't think this is a bug.
/**************************************************************************/
[bugs #8455] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8455>
Project: findutils
Submitted by: Andreas Metzler
On: Mon 04/05/04 at 15:29
Category: find
Severity: 5 - Average
Item Group: None
Resolution: Invalid
Privacy: Public
Assigned to: jay
Originator Name:
Originator Email:
Status: Open
Release: None
Fixed Release: None
Summary: anomaly on large xfs filesystems
Original Submission: This is a copy of <http://bugs.debian.org/241538>.
Andrew Reid writes:
--------------------------
Version: 4.1.20-3
I am having a rather strange difficulty with the "find" command.
For many paths on my system, including all paths in my
account, I get:
> # find <path> -print
> find: <path>: Value too large for defined data type
The failure occurs in some directories but not others, as described
below.
The set-up of the machine is such that user home directories can be
accessed by multiple routes from the start of the file system. I am
not certain that this is relevant, but describe it here for
completeness.
Users' actual home directories are divided into several numbered
"home" directories from the root, like this: /u/home<n>/<user>/
All user home directories are accessible via symlinks from
/u/users/<user> -> /u/home<n>/<user>
There is also a symlink at the root of the filesystem,
/users -> /u/users
The client is an x86 machine. The filesystems are remotely mounted
"xfs" file systems, mounted via NFS from an SGI file server. Each
home<n> subdirectory is separately mounted on the client by way of an
automounter. Most of these reside on separate disks on the server,
except for home1 and home2, which share a physical disk on the server.
The problem occurs for some of the /u/home<n>/ directories, but not
others.
All of these directories are exported identically (to each other) from
the file server, and imported identically by the client. There are
hardware differences between the mounted disks, which correlate with
the "find" problem -- home directories which occupy 48GB disks and use
more than 28GB of them seem to have this problem. The problem is also
common to all of the largest filesystems.
On a Debian "stable" client, importing the same file systems from the
same file server, running the same kernel, but using "find" from
version 4.1.7-2 of findutils, the problem does not occur.
On all systems, these calls work.
# find /u -maxdepth 1
# find /u/users -maxdepth 1
On the problem system in the problem directories, these calls:
# find /u/home<n> -maxdepth 1
fail with the "Value too large" error -- this path argument
is the direct path to the home directory.
Although the filesystem and automounter configuration on these
machines is not trivial, it is nevertheless identical between "stable"
and "testing" machines, and the "find" bug occurs only on the
"testing" machines. There is circumstantial evidence that the problem
involves large xfs filesystems.
--------------------------
He later provided me with the ltrace I am attaching.
thanks, cu andreas
Follow-up Comments
------------------
-------------------------------------------------------
Date: Sun 12/05/04 at 14:46 By: James Youngman <jay>
Hence I don't think this is a bug.
-------------------------------------------------------
Date: Sun 12/05/04 at 14:41 By: James Youngman <jay>
Hmm. See also http://seclists.org/lists/linux-kernel/2000/May/5068.html.
The IRIX documentation for exports(4) says:
32bitclients
Causes the server to mask off the high order 32 bits of directory cookies in NFS version 3 directory operations. This option may be required when clients run 32-bit operating systems that assume the entire cookie is contained in 32 bits and reject responses containing version 3 cookies with high bits on. IRIX 5.3 and Solaris 2.5 are examples of 32-bit operating systems with this behavior, which produces error messages like "Cannot decode response" on directory operations. XFS filesystems on the server can generate cookies with high bits on. Exporting filesystems with the 32bitclients option causes these bits to be masked and prevents error messages.
-------------------------------------------------------
Date: Sun 12/05/04 at 14:18 By: James Youngman <jay>
I have just read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=180065 which seems to state that the problem is in fact a Linux kernel bug for which a fix exists, and there is even a glibc workaround patch for it, too.
-------------------------------------------------------
Date: Thu 12/02/04 at 10:02 By: Tim Waugh <twaugh>
See also:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141167
-------------------------------------------------------
Date: Thu 12/02/04 at 09:11 By: James Youngman <jay>
See also http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141167
-------------------------------------------------------
Date: Mon 11/22/04 at 00:45 By: James Youngman <jay>
I've created a local XFS filesystem with a couple of million files in it (one directory has over 900,000 entries). find searches it in about 15 seconds without failing. I'm not using NFS though.
-------------------------------------------------------
Date: Sat 10/02/04 at 10:48 By: James Youngman <jay>
OK, having looked at the trace output, I still suspect that it is savedir() which is failing. I have a small number of questions.
1. If you use "tar" to copy the directory tree to a local filesystem, can you reproduce the problem? Don't forgert to use the "p" option when unpacking.
The other checks involve getting hold of a copy of the source. If you're not confident with compiling source code, don't worry about it. Otherwise, I have a couple of other suggested tests:
a) Change error() [in file error.c] so that it calls abort(). Then use GDB to get a stack backtrace from the coredump. Send me a copy of the stack backtrace. For the lower levels of the backtrace (say 3 as a guideline) show me which line that corresponds to (the will avoid problems caused by us looking at different versions of the code).
b) Use GDB to single-step through savedir() to figure out why it fails - if indeed (b) shows that it has failed.
Sorry to make you do all the work, but I can't reproduce the problem here.
-------------------------------------------------------
Date: Mon 08/30/04 at 15:54 By: 0 <None>
On Mon, Aug 09, 2004 at 01:01:12PM +0200, Andreas Metzler wrote:
> On 2004-04-01 Andrew Reid <Andrew.Reid@nist.gov> wrote:
> > Package: findutils
> > Version: 4.1.20-3
>
> > I am having a rather strange difficulty with the "find" command.
>
> > For many paths on my system, including all paths in my
> > account, I get:
>
> > > # find <path> -print
> > > find: <path>: Value too large for defined data type
> [...]
>
Thanks for the reply and sorry about my delay in replying -- partially
it's vacation season, and partially I've just been doing other stuff.
> While browsing upstream's bugtracker where I had forwarded the bug to
> I found this in
> http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=8455
>
> -----------------------
> The likely difference between the two versions of find is that they
> use a different version of gnulib, and the updated version is now
> sensitive to this problem. Alternatively, maybe it's a glibc
> difference. Certainly the differences between the find application
> code is minimal.
>
> Looking at the ltrace output, it looks like readdir() is failing. The
> likely bit of affected code is gnulib's savedir.c. That certainly
> should faiil if readdir() fails.
>
> I suspect that somewhere in there is a filename whose base name is
> more than 256 characters. To find out, please try this (on either the
> client or the server):
>
> ls -R1 | awk '(length > 200) {print length, $0;}' | sort -n | tail
This suspicion is not confirmed, alas -- the awk returns nothing
with length > 200. To check that it worked at all, I ratcheted
down the number, and I start to get lots of stuff once it's
less than around 50. Nothing longer than 100. I made no attempt
to refine it beyond that.
> Try picking the last filename from the above and invoking find
> directly on it. The idea here is to pin things down to one path name
> that successfully reproduces the error.
I appreciate the need for diagnosing under controlled conditions,
so I've picked a directory to run it, which I will use for future
tests, if any...
> Lastly, the output of "ltrace" isn't very helpful about the data
> that's returned from the system calls. What do you get if you use
> "strace"? What about "ltrace -S"?
Here's another crack at it -- in case you're curious, this was
test code for what, exactly, Python does to its internal search
paths at start-up time.
Also, recall that the filesystem being examined is an SGI XFS
filesystem which is NFS mounted by the Debian Sarge linux box
which is actually running the "find" command.
The directory:
> poppins[reida]: ls -al
> total 24
> drwxr-xr-x 2 reida user 95 Feb 3 2004 ./
> drwxr-xr-x 22 reida user 4096 Aug 25 20:35 ../
> -rw-r--r-- 1 reida user 20 Feb 3 2004 stuff.py
> -rw-r--r-- 1 reida user 229 Feb 3 2004 stuff.pyc
> -rw-r--r-- 1 reida user 44 Feb 3 2004 stuff.py~
> -rwxr-xr-- 1 reida user 230 Feb 3 2004 test.py*
> -rw-r--r-- 1 reida user 95 Feb 3 2004 test.py~
Debian Woody, with strace output afterwards.
> jeeves[reida]: find . -name "*.py"
> ./test.py
> ./stuff.py
> jeeves[reida]: strace find . -name "*.py"
> execve("/usr/bin/find", ["find", ".", "-name", "*.py"], [/* 35 vars */]) = 0
> uname({sys="Linux", node="jeeves", ...}) = 0
> brk(0) = 0x8053d54
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib", {st_mode=S_IFDIR|0755, st_size=776, ...}) = 0
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=41861, ...}) = 0
> old_mmap(NULL, 41861, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
> close(3) = 0
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "177ELF111 3 3 1 30222"..., 1024) = 1024
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1153784, ...}) = 0
> old_mmap(NULL, 1166560, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001f000
> mprotect(0x40132000, 40160, PROT_NONE) = 0
> old_mmap(0x40132000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x113000) = 0x40132000
> old_mmap(0x40138000, 15584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40138000
> close(3) = 0
> munmap(0x40014000, 41861) = 0
> brk(0) = 0x8053d54
> brk(0x8053d7c) = 0x8053d7c
> brk(0x8054000) = 0x8054000
> time(NULL) = 1093877075
> open(".", O_RDONLY|O_LARGEFILE) = 3
> fchdir(3) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> chdir(".") = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> brk(0x8055000) = 0x8055000
> open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> fstat64(4, {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> brk(0x8058000) = 0x8058000
> getdents64(0x4, 0x8054148, 0x2000, 0) = 208
> getdents64(0x4, 0x8054148, 0x2000, 0) = 0
> close(4) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
> write(1, "./test.pyn", 10./test.py) = 10
> write(1, "./stuff.pyn", 11./stuff.py) = 11
> fchdir(3) = 0
> munmap(0x40014000, 4096) = 0
> _exit(0) = ?
... then Debian Sarge: Since this is the system with the problem,
I have included both strace and ltrace -S output -- they seem to not
quite be the same, so you may of course use whichever is most useful
to you.
> poppins[reida]: find . -name "*.py"
> find: .: Value too large for defined data type
> poppins[reida]: strace find . -name "*.py"
> execve("/usr/bin/find", ["find", ".", "-name", "*.py"], [/* 46 vars */]) = 0
> uname({sys="Linux", node="poppins", ...}) = 0
> brk(0) = 0x80545b4
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib", {st_mode=S_IFDIR|0755, st_size=776, ...}) = 0
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=65341, ...}) = 0
> old_mmap(NULL, 65341, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
> close(3) = 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "177ELF111 3 3 1 200^1"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=1243856, ...}) = 0
> old_mmap(NULL, 1254020, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000
> old_mmap(0x40150000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x127000) = 0x40150000
> old_mmap(0x40158000, 8836, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40158000
> close(3) = 0
> munmap(0x40018000, 65341) = 0
> brk(0) = 0x80545b4
> brk(0x80755b4) = 0x80755b4
> brk(0) = 0x80755b4
> brk(0x8076000) = 0x8076000
> time(NULL) = 1093877299
> open(".", O_RDONLY|O_LARGEFILE) = 3
> fchdir(3) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> chdir(".") = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> fstat64(4, {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> getdents64(4, /* 219 entries */, 8192) = 8168
> _llseek(4, 2144606367, [2144606367], SEEK_SET) = 0
> getdents64(4, /* 144 entries */, 8192) = 5584
> close(4) = 0
> brk(0) = 0x8076000
> brk(0) = 0x8076000
> brk(0x8075000) = 0x8075000
> brk(0) = 0x8075000
> write(2, "find: ", 6find: ) = 6
> write(2, ".", 1.) = 1
> write(2, ": Value too large for defined da"..., 39: Value too large for defined data type) = 39
> write(2, "n", 1 ) = 1
> fchdir(3) = 0
> exit_group(1) = ?
> poppins[reida]: ltrace -S find . -name "*.py"
> SYS_uname(0xbffff70c) = 0
> SYS_brk(NULL) = 0x80545b4
> SYS_mmap(0xbffff4ec, 34, 0x40016c40, 4096, 565) = 0x40017000
> SYS_access(0x40012de4, 0, 0x40016c40, 0x40016e78, 24) = -2
> SYS_open("/etc/ld.so.preload", 0, 010000226744) = -2
> SYS_open("/usr/site/lib/tls/i686/mmx/cmov/"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/mmx/libc."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/cmov/libc"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/mmx/cmov/libc."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/mmx/cmov/libc"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/cmov/libc.so."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/mmx/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = 0
> SYS_open("/etc/ld.so.cache", 0, 00) = 3
> SYS_fstat64(3, 0xbfffefe8, 0x40016c40, 0x40016e60, 2) = 0
> SYS_mmap(0xbfffefc8, 0, 0x40016c40, 3, 0x40016d30) = 0x40018000
> SYS_close(3) = 0
> SYS_access(0x40012de4, 0, 0x40016c40, 0, 524288) = -2
> SYS_open("/lib/libc.so.6", 0, 027777775257) = 3
> SYS_read(3, "177ELF 01 01 01", 512) = 512
> SYS_fstat64(3, 0xbffff098, 0x40016c40, 0x40016e60, 0) = 0
> SYS_mmap(0xbfffef1c, 3, 0x40016c40, 0x132284, 0xbfffef50) = 0x40028000
> SYS_mmap(0xbfffef1c, 0x40028000, 0x40016c40, 0x128000, 0xbfffef68) =
> 0x40150000
> SYS_mmap(0xbfffef1c, 8836, 0x40016c40, 50, 0xbfffef68) = 0x40158000
> SYS_close(3) = 0
> SYS_munmap(0x40018000, 65341) = 0
> __libc_start_main(0x80496a0, 4, 0xbffff954, 0x8052610, 0x8052670
> <unfinished ...>
> setlocale(6, "") = "C"
> bindtextdomain("findutils", "/usr/share/locale" <unfinished ...>
> SYS_brk(NULL) = 0x80545b4
> SYS_brk(0x80755b4) = 0x80755b4
> SYS_brk(NULL) = 0x80755b4
> SYS_brk(0x8076000) = 0x8076000
> <... bindtextdomain resumed> ) = "/usr/share/locale"
> textdomain("findutils") = "findutils"
> time(NULL <unfinished ...>
> SYS_time(0, 0, 0x8052710, 0, 0xbffff954) = 0x41333a1b
> <... time resumed> ) = 1093876251
> getenv("FIND_BLOCK_SIZE") = NULL
> getenv("BLOCK_SIZE") = NULL
> getenv("POSIXLY_CORRECT") = NULL
> strchr("-!(),", '.') = NULL
> strchr("-!(),", '-') = "-!(),"
> malloc(56) = 0x8054638
> strchr("-!(),", '-') = "-!(),"
> strcmp("!", "name") = -77
> strcmp("not", "name") = 14
> strcmp("(", "name") = -70
> strcmp(")", "name") = -69
> strcmp(",", "name") = -66
> strcmp("a", "name") = -13
> strcmp("amin", "name") = -13
> strcmp("and", "name") = -13
> strcmp("anewer", "name") = -13
> strcmp("atime", "name") = -13
> strcmp("cmin", "name") = -11
> strcmp("cnewer", "name") = -11
> strcmp("ctime", "name") = -11
> strcmp("daystart", "name") = -10
> strcmp("depth", "name") = -10
> strcmp("empty", "name") = -9
> strcmp("exec", "name") = -9
> strcmp("false", "name") = -8
> strcmp("fls", "name") = -8
> strcmp("follow", "name") = -8
> strcmp("fprint", "name") = -8
> strcmp("fprint0", "name") = -8
> strcmp("fprintf", "name") = -8
> strcmp("fstype", "name") = -8
> strcmp("gid", "name") = -7
> strcmp("group", "name") = -7
> strcmp("help", "name") = -6
> strcmp("-help", "name") = -65
> strcmp("ilname", "name") = -5
> strcmp("iname", "name") = -5
> strcmp("inum", "name") = -5
> strcmp("ipath", "name") = -5
> strcmp("iregex", "name") = -5
> strcmp("links", "name") = -2
> strcmp("lname", "name") = -2
> strcmp("ls", "name") = -2
> strcmp("maxdepth", "name") = -1
> strcmp("mindepth", "name") = -1
> strcmp("mmin", "name") = -1
> strcmp("mount", "name") = -1
> strcmp("mtime", "name") = -1
> strcmp("name", "name") = 0
> malloc(56) = 0x8054678
> malloc(56) = 0x80546b8
> malloc(56) = 0x80546f8
> malloc(56) = 0x8054738
> malloc(56) = 0x8054778
> open64(".", 0, 01001242620 <unfinished ...>
> SYS_open(".", 32768, 00) = 3
> <... open64 resumed> ) = 3
> fchdir(3 <unfinished ...>
> SYS_fchdir(3, 32768, 4, 0xbffffabb, 0xbffff954) = 0
> <... fchdir resumed> ) = 0
> __lxstat64(3, ".", 0x8054500 <unfinished ...>
> SYS_lstat64(0x8052865, 0x8054500, 0x40157550, 0x4015a008, 0x8054500) = 0
> <... __lxstat64 resumed> ) = 0
> strchr("-!(),", '.') = NULL
> strlen(".") = 1
> __lxstat64(3, ".", 0xbffff850 <unfinished ...>
> SYS_lstat64(0xbffffab9, 0xbffff850, 0x40157550, 0x4015a008, 0xbffff850)
> = 0
> <... __lxstat64 resumed> ) = 0
> chdir("." <unfinished ...>
> SYS_chdir(0xbffffab9, 0xbffff850, 1, 0, 0xbffffab9) = 0
> <... chdir resumed> ) = 0
> __lxstat64(3, ".", 0xbffff7f0 <unfinished ...>
> SYS_lstat64(0x8052865, 0xbffff7f0, 0x40157550, 0x4015a008, 0xbffff7f0) =
> 0
> <... __lxstat64 resumed> ) = 0
> __lxstat64(3, ".", 0xbffff750 <unfinished ...>
> SYS_lstat64(0x8052865, 0xbffff750, 0x40157550, 0x4015a008, 0xbffff750) =
> 0
> <... __lxstat64 resumed> ) = 0
> realloc(NULL, 512) = 0x80547b8
> fnmatch("*.py", ".", 4) = 1
> strlen(".") = 1
> __errno_location() = 0x40157900
> opendir("." <unfinished ...>
> SYS_open("/dev/null", 67584, 010005272520) = -20
> SYS_open(".", 100352, 010005272520) = 4
> SYS_fstat64(4, 0xbffff54c, 0x40157550, 0x4015a008, 0xbffff54c) = 0
> SYS_fcntl64(4, 2, 1, 1, 0x40157550) = 0
> <... opendir resumed> ) = 0x80549c0
> malloc(512) = 0x80569f8
> __errno_location() = 0x40157900
> readdir(0x80549c0 <unfinished ...>
> SYS_getdents64(4, 0x80549f0, 8192, 0x40157900, 0x40157550) = 208
> SYS__llseek(4, 0, 0x6c2c6bd7, 0xbffff51c, 0) = 0
> <... readdir resumed> ) = 0x80549f0
> readdir(0x80549c0) = 0x8054a00
> readdir(0x80549c0) = 0x8054a10
> strlen("stuff.py~") = 9
> memcpy(0x80569f8, "stuff.py~", 10) = 0x80569f8
> readdir(0x80549c0) = 0x8054a28
> strlen("stuff.pyc") = 9
> memcpy(0x8056a02, "stuff.pyc", 10) = 0x8056a02
> readdir(0x80549c0) = 0x8054a40
> strlen("test.py") = 7
> memcpy(0x8056a0c, "test.py", 8) = 0x8056a0c
> readdir(0x80549c0) = 0x8054a58
> strlen("test.py~") = 8
> memcpy(0x8056a14, "test.py~", 9) = 0x8056a14
> readdir(0x80549c0 <unfinished ...>
> SYS_getdents64(4, 0x80549f0, 8192, 0x40157900, 0x40157550) = 32
> <... readdir resumed> ) = NULL
> __errno_location() = 0x40157900
> closedir(0x80549c0 <unfinished ...>
> SYS_close(4) = 0
> <... closedir resumed> ) = 0
> free(0x80569f8 <unfinished ...>
> SYS_brk(NULL) = 0x8076000
> SYS_brk(NULL) = 0x8076000
> SYS_brk(0x8075000) = 0x8075000
> SYS_brk(NULL) = 0x8075000
> <... free resumed> ) = <void>
> error(0, 75, 0x8053b72, 0xbffffab9, 0x4002fa10 <unfinished ...>
> SYS_write(2, "find: ", 6find: ) = 6
> SYS_write(2, ".", 1.) = 1
> SYS_write(2, ": Value too large for defined da"..., 39: Value too large
> for defined data type) = 39
> SYS_write(2, "n", 1
> ) = 1
> <... error resumed> ) = 0
> fchdir(3 <unfinished ...>
> SYS_fchdir(3, 0, 0, 0, 0xbffffab9) = 0
> <... fchdir resumed> ) = 0
> strchr("-!(),", '-') = "-!(),"
> exit(1 <unfinished ...>
> SYS_exit_group(1) = <void>
> SYS_exit(1 <unfinished ...>
> +++ exited (status 1) +++
> poppins[reida]:
-------------------------------------------------------
Date: Mon 04/05/04 at 16:31 By: James Youngman <jay>
The likely difference between the two versions of find is that they use a different version of gnulib, and the updated version is now sensitive to this problem. Alternatively, maybe it's a glibc difference. Certainly the differences between the find application code is minimal.
Looking at the ltrace output, it looks like readdir() is failing. The likely bit of affected code is gnulib's savedir.c. That certainly should faiil if readdir() fails.
I suspect that somewhere in there is a filename whose base
name is more than 256 characters. To find out, please try this (on either the client or the server):
ls -R1 | awk '(length > 200) {print length, $0;}' | sort -n | tail
Try picking the last filename from the above and invoking find directly on it. The idea here is to pin things down to one path name that successfully reproduces the error.
Lastly, the output of "ltrace" isn't very helpful about the data that's returned from the system calls. What do you get if you use "strace"? What about "ltrace -S"?
CC List
-------
CC Address | Comment
------------------------------------+-----------------------------
timwaugh<twaugh --AT-- redhat --DOT-- com> | Handling similar bug for Red Hat.
241538 --AT-- bugs --DOT-- debian --DOT-- org | original report
andrewreid<andrew --DOT-- reid --AT-- nist --DOT-- gov> | Bug forwarded to upstream authors
File Attachments
-------------------
-------------------------------------------------------
Date: Mon 04/05/04 at 15:29 Name: findbug.ltrace Size: 30.51KB By: ametzler
ltrace output
http://savannah.gnu.org/bugs/download.php?item_id=8455&item_file_id=1169
For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=8455>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Metzler <ametzler@debian.org>:
Bug#241538; Package findutils.
(full text, mbox, link).
Acknowledgement sent to James Youngman <noreply@savannah.gnu.org>:
Extra info received and forwarded to list. Copy sent to Andreas Metzler <ametzler@debian.org>.
(full text, mbox, link).
Message #52 received at 241538@bugs.debian.org (full text, mbox, reply):
This mail is an automated notification from the bugs tracker
of the project: findutils.
/**************************************************************************/
[bugs #8455] Latest Modifications:
Changes by:
James Youngman <jay@gnu.org>
'Date:
Mon 01/03/2005 at 22:15 (GMT)
What | Removed | Added
---------------------------------------------------------------------------
Status | Open | Closed
/**************************************************************************/
[bugs #8455] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8455>
Project: findutils
Submitted by: Andreas Metzler
On: Mon 04/05/2004 at 15:29
Category: find
Severity: 5 - Average
Item Group: None
Resolution: Invalid
Privacy: Public
Assigned to: jay
Originator Name:
Originator Email:
Status: Closed
Release: None
Fixed Release: None
Summary: anomaly on large xfs filesystems
Original Submission: This is a copy of <http://bugs.debian.org/241538>.
Andrew Reid writes:
--------------------------
Version: 4.1.20-3
I am having a rather strange difficulty with the "find" command.
For many paths on my system, including all paths in my
account, I get:
> # find <path> -print
> find: <path>: Value too large for defined data type
The failure occurs in some directories but not others, as described
below.
The set-up of the machine is such that user home directories can be
accessed by multiple routes from the start of the file system. I am
not certain that this is relevant, but describe it here for
completeness.
Users' actual home directories are divided into several numbered
"home" directories from the root, like this: /u/home<n>/<user>/
All user home directories are accessible via symlinks from
/u/users/<user> -> /u/home<n>/<user>
There is also a symlink at the root of the filesystem,
/users -> /u/users
The client is an x86 machine. The filesystems are remotely mounted
"xfs" file systems, mounted via NFS from an SGI file server. Each
home<n> subdirectory is separately mounted on the client by way of an
automounter. Most of these reside on separate disks on the server,
except for home1 and home2, which share a physical disk on the server.
The problem occurs for some of the /u/home<n>/ directories, but not
others.
All of these directories are exported identically (to each other) from
the file server, and imported identically by the client. There are
hardware differences between the mounted disks, which correlate with
the "find" problem -- home directories which occupy 48GB disks and use
more than 28GB of them seem to have this problem. The problem is also
common to all of the largest filesystems.
On a Debian "stable" client, importing the same file systems from the
same file server, running the same kernel, but using "find" from
version 4.1.7-2 of findutils, the problem does not occur.
On all systems, these calls work.
# find /u -maxdepth 1
# find /u/users -maxdepth 1
On the problem system in the problem directories, these calls:
# find /u/home<n> -maxdepth 1
fail with the "Value too large" error -- this path argument
is the direct path to the home directory.
Although the filesystem and automounter configuration on these
machines is not trivial, it is nevertheless identical between "stable"
and "testing" machines, and the "find" bug occurs only on the
"testing" machines. There is circumstantial evidence that the problem
involves large xfs filesystems.
--------------------------
He later provided me with the ltrace I am attaching.
thanks, cu andreas
Follow-up Comments
------------------
-------------------------------------------------------
Date: Sun 12/05/2004 at 14:46 By: James Youngman <jay>
Hence I don't think this is a bug.
-------------------------------------------------------
Date: Sun 12/05/2004 at 14:41 By: James Youngman <jay>
Hmm. See also http://seclists.org/lists/linux-kernel/2000/May/5068.html.
The IRIX documentation for exports(4) says:
32bitclients
Causes the server to mask off the high order 32 bits of directory cookies in NFS version 3 directory operations. This option may be required when clients run 32-bit operating systems that assume the entire cookie is contained in 32 bits and reject responses containing version 3 cookies with high bits on. IRIX 5.3 and Solaris 2.5 are examples of 32-bit operating systems with this behavior, which produces error messages like "Cannot decode response" on directory operations. XFS filesystems on the server can generate cookies with high bits on. Exporting filesystems with the 32bitclients option causes these bits to be masked and prevents error messages.
-------------------------------------------------------
Date: Sun 12/05/2004 at 14:18 By: James Youngman <jay>
I have just read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=180065 which seems to state that the problem is in fact a Linux kernel bug for which a fix exists, and there is even a glibc workaround patch for it, too.
-------------------------------------------------------
Date: Thu 12/02/2004 at 10:02 By: Tim Waugh <twaugh>
See also:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141167
-------------------------------------------------------
Date: Thu 12/02/2004 at 09:11 By: James Youngman <jay>
See also http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141167
-------------------------------------------------------
Date: Mon 11/22/2004 at 00:45 By: James Youngman <jay>
I've created a local XFS filesystem with a couple of million files in it (one directory has over 900,000 entries). find searches it in about 15 seconds without failing. I'm not using NFS though.
-------------------------------------------------------
Date: Sat 10/02/2004 at 10:48 By: James Youngman <jay>
OK, having looked at the trace output, I still suspect that it is savedir() which is failing. I have a small number of questions.
1. If you use "tar" to copy the directory tree to a local filesystem, can you reproduce the problem? Don't forgert to use the "p" option when unpacking.
The other checks involve getting hold of a copy of the source. If you're not confident with compiling source code, don't worry about it. Otherwise, I have a couple of other suggested tests:
a) Change error() [in file error.c] so that it calls abort(). Then use GDB to get a stack backtrace from the coredump. Send me a copy of the stack backtrace. For the lower levels of the backtrace (say 3 as a guideline) show me which line that corresponds to (the will avoid problems caused by us looking at different versions of the code).
b) Use GDB to single-step through savedir() to figure out why it fails - if indeed (b) shows that it has failed.
Sorry to make you do all the work, but I can't reproduce the problem here.
-------------------------------------------------------
Date: Mon 08/30/2004 at 15:54 By: 0 <None>
On Mon, Aug 09, 2004 at 01:01:12PM +0200, Andreas Metzler wrote:
> On 2004-04-01 Andrew Reid <Andrew.Reid@nist.gov> wrote:
> > Package: findutils
> > Version: 4.1.20-3
>
> > I am having a rather strange difficulty with the "find" command.
>
> > For many paths on my system, including all paths in my
> > account, I get:
>
> > > # find <path> -print
> > > find: <path>: Value too large for defined data type
> [...]
>
Thanks for the reply and sorry about my delay in replying -- partially
it's vacation season, and partially I've just been doing other stuff.
> While browsing upstream's bugtracker where I had forwarded the bug to
> I found this in
> http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=8455
>
> -----------------------
> The likely difference between the two versions of find is that they
> use a different version of gnulib, and the updated version is now
> sensitive to this problem. Alternatively, maybe it's a glibc
> difference. Certainly the differences between the find application
> code is minimal.
>
> Looking at the ltrace output, it looks like readdir() is failing. The
> likely bit of affected code is gnulib's savedir.c. That certainly
> should faiil if readdir() fails.
>
> I suspect that somewhere in there is a filename whose base name is
> more than 256 characters. To find out, please try this (on either the
> client or the server):
>
> ls -R1 | awk '(length > 200) {print length, $0;}' | sort -n | tail
This suspicion is not confirmed, alas -- the awk returns nothing
with length > 200. To check that it worked at all, I ratcheted
down the number, and I start to get lots of stuff once it's
less than around 50. Nothing longer than 100. I made no attempt
to refine it beyond that.
> Try picking the last filename from the above and invoking find
> directly on it. The idea here is to pin things down to one path name
> that successfully reproduces the error.
I appreciate the need for diagnosing under controlled conditions,
so I've picked a directory to run it, which I will use for future
tests, if any...
> Lastly, the output of "ltrace" isn't very helpful about the data
> that's returned from the system calls. What do you get if you use
> "strace"? What about "ltrace -S"?
Here's another crack at it -- in case you're curious, this was
test code for what, exactly, Python does to its internal search
paths at start-up time.
Also, recall that the filesystem being examined is an SGI XFS
filesystem which is NFS mounted by the Debian Sarge linux box
which is actually running the "find" command.
The directory:
> poppins[reida]: ls -al
> total 24
> drwxr-xr-x 2 reida user 95 Feb 3 2004 ./
> drwxr-xr-x 22 reida user 4096 Aug 25 20:35 ../
> -rw-r--r-- 1 reida user 20 Feb 3 2004 stuff.py
> -rw-r--r-- 1 reida user 229 Feb 3 2004 stuff.pyc
> -rw-r--r-- 1 reida user 44 Feb 3 2004 stuff.py~
> -rwxr-xr-- 1 reida user 230 Feb 3 2004 test.py*
> -rw-r--r-- 1 reida user 95 Feb 3 2004 test.py~
Debian Woody, with strace output afterwards.
> jeeves[reida]: find . -name "*.py"
> ./test.py
> ./stuff.py
> jeeves[reida]: strace find . -name "*.py"
> execve("/usr/bin/find", ["find", ".", "-name", "*.py"], [/* 35 vars */]) = 0
> uname({sys="Linux", node="jeeves", ...}) = 0
> brk(0) = 0x8053d54
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx", 0xbfffef04) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib", {st_mode=S_IFDIR|0755, st_size=776, ...}) = 0
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=41861, ...}) = 0
> old_mmap(NULL, 41861, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
> close(3) = 0
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "177ELF111 3 3 1 30222"..., 1024) = 1024
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1153784, ...}) = 0
> old_mmap(NULL, 1166560, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001f000
> mprotect(0x40132000, 40160, PROT_NONE) = 0
> old_mmap(0x40132000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x113000) = 0x40132000
> old_mmap(0x40138000, 15584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40138000
> close(3) = 0
> munmap(0x40014000, 41861) = 0
> brk(0) = 0x8053d54
> brk(0x8053d7c) = 0x8053d7c
> brk(0x8054000) = 0x8054000
> time(NULL) = 1093877075
> open(".", O_RDONLY|O_LARGEFILE) = 3
> fchdir(3) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> chdir(".") = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> brk(0x8055000) = 0x8055000
> open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> fstat64(4, {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> brk(0x8058000) = 0x8058000
> getdents64(0x4, 0x8054148, 0x2000, 0) = 208
> getdents64(0x4, 0x8054148, 0x2000, 0) = 0
> close(4) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=95, ...}) = 0
> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
> write(1, "./test.pyn", 10./test.py) = 10
> write(1, "./stuff.pyn", 11./stuff.py) = 11
> fchdir(3) = 0
> munmap(0x40014000, 4096) = 0
> _exit(0) = ?
... then Debian Sarge: Since this is the system with the problem,
I have included both strace and ltrace -S output -- they seem to not
quite be the same, so you may of course use whichever is most useful
to you.
> poppins[reida]: find . -name "*.py"
> find: .: Value too large for defined data type
> poppins[reida]: strace find . -name "*.py"
> execve("/usr/bin/find", ["find", ".", "-name", "*.py"], [/* 46 vars */]) = 0
> uname({sys="Linux", node="poppins", ...}) = 0
> brk(0) = 0x80545b4
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/i686", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/tls", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/i686", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/mmx", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib/cmov", 0xbffff0a8) = -1 ENOENT (No such file or directory)
> open("/usr/site/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> stat64("/usr/site/lib", {st_mode=S_IFDIR|0755, st_size=776, ...}) = 0
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=65341, ...}) = 0
> old_mmap(NULL, 65341, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
> close(3) = 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
> open("/lib/libc.so.6", O_RDONLY) = 3
> read(3, "177ELF111 3 3 1 200^1"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=1243856, ...}) = 0
> old_mmap(NULL, 1254020, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000
> old_mmap(0x40150000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x127000) = 0x40150000
> old_mmap(0x40158000, 8836, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40158000
> close(3) = 0
> munmap(0x40018000, 65341) = 0
> brk(0) = 0x80545b4
> brk(0x80755b4) = 0x80755b4
> brk(0) = 0x80755b4
> brk(0x8076000) = 0x8076000
> time(NULL) = 1093877299
> open(".", O_RDONLY|O_LARGEFILE) = 3
> fchdir(3) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> chdir(".") = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat64(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
> fstat64(4, {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> getdents64(4, /* 219 entries */, 8192) = 8168
> _llseek(4, 2144606367, [2144606367], SEEK_SET) = 0
> getdents64(4, /* 144 entries */, 8192) = 5584
> close(4) = 0
> brk(0) = 0x8076000
> brk(0) = 0x8076000
> brk(0x8075000) = 0x8075000
> brk(0) = 0x8075000
> write(2, "find: ", 6find: ) = 6
> write(2, ".", 1.) = 1
> write(2, ": Value too large for defined da"..., 39: Value too large for defined data type) = 39
> write(2, "n", 1 ) = 1
> fchdir(3) = 0
> exit_group(1) = ?
> poppins[reida]: ltrace -S find . -name "*.py"
> SYS_uname(0xbffff70c) = 0
> SYS_brk(NULL) = 0x80545b4
> SYS_mmap(0xbffff4ec, 34, 0x40016c40, 4096, 565) = 0x40017000
> SYS_access(0x40012de4, 0, 0x40016c40, 0x40016e78, 24) = -2
> SYS_open("/etc/ld.so.preload", 0, 010000226744) = -2
> SYS_open("/usr/site/lib/tls/i686/mmx/cmov/"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/mmx/libc."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/cmov/libc"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/i686/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/mmx/cmov/libc."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/tls/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/mmx/cmov/libc"..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/cmov/libc.so."..., 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/i686/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/mmx/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/mmx/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/cmov/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = -2
> SYS_open("/usr/site/lib/libc.so.6", 0, 00) = -2
> SYS_stat64(0xbffff040, 0xbffff098, 0x40016c40, 0x40016e60, 2) = 0
> SYS_open("/etc/ld.so.cache", 0, 00) = 3
> SYS_fstat64(3, 0xbfffefe8, 0x40016c40, 0x40016e60, 2) = 0
> SYS_mmap(0xbfffefc8, 0, 0x40016c40, 3, 0x40016d30) = 0x40018000
> SYS_close(3) = 0
> SYS_access(0x40012de4, 0, 0x40016c40, 0, 524288) = -2
> SYS_open("/lib/libc.so.6", 0, 027777775257) = 3
> SYS_read(3, "177ELF 01 01 01", 512) = 512
> SYS_fstat64(3, 0xbffff098, 0x40016c40, 0x40016e60, 0) = 0
> SYS_mmap(0xbfffef1c, 3, 0x40016c40, 0x132284, 0xbfffef50) = 0x40028000
> SYS_mmap(0xbfffef1c, 0x40028000, 0x40016c40, 0x128000, 0xbfffef68) =
> 0x40150000
> SYS_mmap(0xbfffef1c, 8836, 0x40016c40, 50, 0xbfffef68) = 0x40158000
> SYS_close(3) = 0
> SYS_munmap(0x40018000, 65341) = 0
> __libc_start_main(0x80496a0, 4, 0xbffff954, 0x8052610, 0x8052670
> <unfinished ...>
> setlocale(6, "") = "C"
> bindtextdomain("findutils", "/usr/share/locale" <unfinished ...>
> SYS_brk(NULL) = 0x80545b4
> SYS_brk(0x80755b4) = 0x80755b4
> SYS_brk(NULL) = 0x80755b4
> SYS_brk(0x8076000) = 0x8076000
> <... bindtextdomain resumed> ) = "/usr/share/locale"
> textdomain("findutils") = "findutils"
> time(NULL <unfinished ...>
> SYS_time(0, 0, 0x8052710, 0, 0xbffff954) = 0x41333a1b
> <... time resumed> ) = 1093876251
> getenv("FIND_BLOCK_SIZE") = NULL
> getenv("BLOCK_SIZE") = NULL
> getenv("POSIXLY_CORRECT") = NULL
> strchr("-!(),", '.') = NULL
> strchr("-!(),", '-') = "-!(),"
> malloc(56) = 0x8054638
> strchr("-!(),", '-') = "-!(),"
> strcmp("!", "name") = -77
> strcmp("not", "name") = 14
> strcmp("(", "name") = -70
> strcmp(")", "name") = -69
> strcmp(",", "name") = -66
> strcmp("a", "name") = -13
> strcmp("amin", "name") = -13
> strcmp("and", "name") = -13
> strcmp("anewer", "name") = -13
> strcmp("atime", "name") = -13
> strcmp("cmin", "name") = -11
> strcmp("cnewer", "name") = -11
> strcmp("ctime", "name") = -11
> strcmp("daystart", "name") = -10
> strcmp("depth", "name") = -10
> strcmp("empty", "name") = -9
> strcmp("exec", "name") = -9
> strcmp("false", "name") = -8
> strcmp("fls", "name") = -8
> strcmp("follow", "name") = -8
> strcmp("fprint", "name") = -8
> strcmp("fprint0", "name") = -8
> strcmp("fprintf", "name") = -8
> strcmp("fstype", "name") = -8
> strcmp("gid", "name") = -7
> strcmp("group", "name") = -7
> strcmp("help", "name") = -6
> strcmp("-help", "name") = -65
> strcmp("ilname", "name") = -5
> strcmp("iname", "name") = -5
> strcmp("inum", "name") = -5
> strcmp("ipath", "name") = -5
> strcmp("iregex", "name") = -5
> strcmp("links", "name") = -2
> strcmp("lname", "name") = -2
> strcmp("ls", "name") = -2
> strcmp("maxdepth", "name") = -1
> strcmp("mindepth", "name") = -1
> strcmp("mmin", "name") = -1
> strcmp("mount", "name") = -1
> strcmp("mtime", "name") = -1
> strcmp("name", "name") = 0
> malloc(56) = 0x8054678
> malloc(56) = 0x80546b8
> malloc(56) = 0x80546f8
> malloc(56) = 0x8054738
> malloc(56) = 0x8054778
> open64(".", 0, 01001242620 <unfinished ...>
> SYS_open(".", 32768, 00) = 3
> <... open64 resumed> ) = 3
> fchdir(3 <unfinished ...>
> SYS_fchdir(3, 32768, 4, 0xbffffabb, 0xbffff954) = 0
> <... fchdir resumed> ) = 0
> __lxstat64(3, ".", 0x8054500 <unfinished ...>
> SYS_lstat64(0x8052865, 0x8054500, 0x40157550, 0x4015a008, 0x8054500) = 0
> <... __lxstat64 resumed> ) = 0
> strchr("-!(),", '.') = NULL
> strlen(".") = 1
> __lxstat64(3, ".", 0xbffff850 <unfinished ...>
> SYS_lstat64(0xbffffab9, 0xbffff850, 0x40157550, 0x4015a008, 0xbffff850)
> = 0
> <... __lxstat64 resumed> ) = 0
> chdir("." <unfinished ...>
> SYS_chdir(0xbffffab9, 0xbffff850, 1, 0, 0xbffffab9) = 0
> <... chdir resumed> ) = 0
> __lxstat64(3, ".", 0xbffff7f0 <unfinished ...>
> SYS_lstat64(0x8052865, 0xbffff7f0, 0x40157550, 0x4015a008, 0xbffff7f0) =
> 0
> <... __lxstat64 resumed> ) = 0
> __lxstat64(3, ".", 0xbffff750 <unfinished ...>
> SYS_lstat64(0x8052865, 0xbffff750, 0x40157550, 0x4015a008, 0xbffff750) =
> 0
> <... __lxstat64 resumed> ) = 0
> realloc(NULL, 512) = 0x80547b8
> fnmatch("*.py", ".", 4) = 1
> strlen(".") = 1
> __errno_location() = 0x40157900
> opendir("." <unfinished ...>
> SYS_open("/dev/null", 67584, 010005272520) = -20
> SYS_open(".", 100352, 010005272520) = 4
> SYS_fstat64(4, 0xbffff54c, 0x40157550, 0x4015a008, 0xbffff54c) = 0
> SYS_fcntl64(4, 2, 1, 1, 0x40157550) = 0
> <... opendir resumed> ) = 0x80549c0
> malloc(512) = 0x80569f8
> __errno_location() = 0x40157900
> readdir(0x80549c0 <unfinished ...>
> SYS_getdents64(4, 0x80549f0, 8192, 0x40157900, 0x40157550) = 208
> SYS__llseek(4, 0, 0x6c2c6bd7, 0xbffff51c, 0) = 0
> <... readdir resumed> ) = 0x80549f0
> readdir(0x80549c0) = 0x8054a00
> readdir(0x80549c0) = 0x8054a10
> strlen("stuff.py~") = 9
> memcpy(0x80569f8, "stuff.py~", 10) = 0x80569f8
> readdir(0x80549c0) = 0x8054a28
> strlen("stuff.pyc") = 9
> memcpy(0x8056a02, "stuff.pyc", 10) = 0x8056a02
> readdir(0x80549c0) = 0x8054a40
> strlen("test.py") = 7
> memcpy(0x8056a0c, "test.py", 8) = 0x8056a0c
> readdir(0x80549c0) = 0x8054a58
> strlen("test.py~") = 8
> memcpy(0x8056a14, "test.py~", 9) = 0x8056a14
> readdir(0x80549c0 <unfinished ...>
> SYS_getdents64(4, 0x80549f0, 8192, 0x40157900, 0x40157550) = 32
> <... readdir resumed> ) = NULL
> __errno_location() = 0x40157900
> closedir(0x80549c0 <unfinished ...>
> SYS_close(4) = 0
> <... closedir resumed> ) = 0
> free(0x80569f8 <unfinished ...>
> SYS_brk(NULL) = 0x8076000
> SYS_brk(NULL) = 0x8076000
> SYS_brk(0x8075000) = 0x8075000
> SYS_brk(NULL) = 0x8075000
> <... free resumed> ) = <void>
> error(0, 75, 0x8053b72, 0xbffffab9, 0x4002fa10 <unfinished ...>
> SYS_write(2, "find: ", 6find: ) = 6
> SYS_write(2, ".", 1.) = 1
> SYS_write(2, ": Value too large for defined da"..., 39: Value too large
> for defined data type) = 39
> SYS_write(2, "n", 1
> ) = 1
> <... error resumed> ) = 0
> fchdir(3 <unfinished ...>
> SYS_fchdir(3, 0, 0, 0, 0xbffffab9) = 0
> <... fchdir resumed> ) = 0
> strchr("-!(),", '-') = "-!(),"
> exit(1 <unfinished ...>
> SYS_exit_group(1) = <void>
> SYS_exit(1 <unfinished ...>
> +++ exited (status 1) +++
> poppins[reida]:
-------------------------------------------------------
Date: Mon 04/05/2004 at 16:31 By: James Youngman <jay>
The likely difference between the two versions of find is that they use a different version of gnulib, and the updated version is now sensitive to this problem. Alternatively, maybe it's a glibc difference. Certainly the differences between the find application code is minimal.
Looking at the ltrace output, it looks like readdir() is failing. The likely bit of affected code is gnulib's savedir.c. That certainly should faiil if readdir() fails.
I suspect that somewhere in there is a filename whose base
name is more than 256 characters. To find out, please try this (on either the client or the server):
ls -R1 | awk '(length > 200) {print length, $0;}' | sort -n | tail
Try picking the last filename from the above and invoking find directly on it. The idea here is to pin things down to one path name that successfully reproduces the error.
Lastly, the output of "ltrace" isn't very helpful about the data that's returned from the system calls. What do you get if you use "strace"? What about "ltrace -S"?
CC List
-------
CC Address | Comment
------------------------------------+-----------------------------
timwaugh<twaugh --AT-- redhat --DOT-- com> | Handling similar bug for Red Hat.
241538 --AT-- bugs --DOT-- debian --DOT-- org | original report
andrewreid<andrew --DOT-- reid --AT-- nist --DOT-- gov> | Bug forwarded to upstream authors
File Attachments
-------------------
-------------------------------------------------------
Date: Mon 04/05/2004 at 15:29 Name: findbug.ltrace Size: 30.51KB By: ametzler
ltrace output
http://savannah.gnu.org/bugs/download.php?item_id=8455&item_file_id=1169
For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=8455>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Reply sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
You have taken responsibility.
(full text, mbox, link).
Notification sent to Andrew Reid <Andrew.Reid@nist.gov>:
Bug acknowledged by developer.
(full text, mbox, link).
Message #57 received at 241538-done@bugs.debian.org (full text, mbox, reply):
----- Forwarded message from James Youngman <noreply@savannah.gnu.org> -----
From: James Youngman <noreply@savannah.gnu.org>
To: 241538@bugs.debian.org
Date: Mon, 03 Jan 2005 14:16:20 -0800
This mail is an automated notification from the bugs tracker
of the project: findutils.
/**************************************************************************/
[bugs #8455] Latest Modifications:
Changes by:
James Youngman <jay@gnu.org>
'Date:
Mon 01/03/2005 at 22:15 (GMT)
What | Removed | Added
---------------------------------------------------------------------------
Status | Open | Closed
/**************************************************************************/
[bugs #8455] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8455>
[...]
-------------------------------------------------------
Date: Sun 12/05/2004 at 14:46 By: James Youngman <jay>
Hence I don't think this is a bug.
-------------------------------------------------------
Date: Sun 12/05/2004 at 14:41 By: James Youngman <jay>
Hmm. See also http://seclists.org/lists/linux-kernel/2000/May/5068.html.
The IRIX documentation for exports(4) says:
32bitclients
Causes the server to mask off the high order 32 bits of directory cookies in NFS version 3 directory operations. This option may be required when clients run 32-bit operating systems that assume the entire cookie is contained in 32 bits and reject responses containing version 3 cookies with high bits on. IRIX 5.3 and Solaris 2.5 are examples of 32-bit operating systems with this behavior, which produces error messages like "Cannot decode response" on directory operations. XFS filesystems on the server can generate cookies with high bits on. Exporting filesystems with the 32bitclients option causes these bits to be masked and prevents error messages.
-------------------------------------------------------
Date: Sun 12/05/2004 at 14:18 By: James Youngman <jay>
I have just read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=180065 which seems to state that the problem is in fact a Linux kernel bug for which a fix exists, and there is even a glibc workaround patch for it, too.
-------------------------------------------------------
Date: Thu 12/02/2004 at 10:02 By: Tim Waugh <twaugh>
See also:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141167
[...]
----- End forwarded message -----
Send a report that this bug log contains spam.
Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.