Mon 02 Mar 2009 04:31:39 AM UTC, comment #5:
Hmmm, I agree your fix does work, but I'm not sure I agree that is is treating the root problem. Here is what I was about to post, prior to finding your fix (this is all based on http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=fa4c6418bb165c507f4f755d27d7ef9c34712f89 although I believe the core idea still applies)
I did some poking around with gdb to try to confirm your suspicion, and eventually found something interesting by inspecting calls to following_links():
To reproduce, setup the failing test case in the find directory
CFLAGS="-g -ggdb -g3" ./configure
make
cd find
gdb find
display state
break following_links
c (repeated until program finishes)
(gdb) display state
(gdb) break following_links
Breakpoint 1 at 0x40bc48: file util.c, line 602.
(gdb) run -H tmp/LINK tmp/BROKEN tmp -printf "H1: %y %d %p\n"
Starting program: /home/nfortino/findutils/find/find -H tmp/LINK tmp/BROKEN tmp -printf "H1: %y %d %p\n"
[Thread debugging using libthread_db enabled]
H1: f 0 tmp/LINK
[New Thread 0x7fe5ca8766f0 (LWP 444)]
[Switching to Thread 0x7fe5ca8766f0 (LWP 444)]
Breakpoint 1, following_links () at util.c:602
602 switch (options.symlink_handling)
1: state = {curdepth = 0, have_stat = false, have_type = true, type = 41471,
rel_pathname = 0x64a4c0 "tmp/BROKEN", cwd_dir_fd = -100,
starting_path_length = 10, stop_at_current_level = false, exit_status = 0,
execdirs_outstanding = false}
(gdb) c
Continuing.
Breakpoint 1, following_links () at util.c:602
602 switch (options.symlink_handling)
1: state = {curdepth = 0, have_stat = true, have_type = true, type = 41471,
rel_pathname = 0x64a4c0 "tmp/BROKEN", cwd_dir_fd = -100,
starting_path_length = 10, stop_at_current_level = false, exit_status = 0,
execdirs_outstanding = false}
(gdb) c
Continuing.
H1: l 0 tmp/BROKEN
H1: d 0 tmp
Breakpoint 1, following_links () at util.c:602
602 switch (options.symlink_handling)
1: state = {curdepth = 0, have_stat = false, have_type = true, type = 40960,
rel_pathname = 0x64a4c0 "tmp/LINK", cwd_dir_fd = 8,
starting_path_length = 3, stop_at_current_level = false, exit_status = 0,
execdirs_outstanding = false}
(gdb) c
Continuing.
H1: f 1 tmp/LINK
Breakpoint 1, following_links () at util.c:602
602 switch (options.symlink_handling)
1: state = {curdepth = 1, have_stat = false, have_type = true, type = 40960,
rel_pathname = 0x64cd40 "LINK", cwd_dir_fd = 8, starting_path_length = 3,
stop_at_current_level = false, exit_status = 0, execdirs_outstanding = false}
(gdb) c
Continuing.
H1: l 1 tmp/BROKEN
The interesting part (obviously) of the output comes in the state directly before 'H1: f 1 tmp/LINK' is printed. Notice that state.curdepth = 0 (!), not 1. Running this same test on a ubuntu machine never calls following_links() for tmp/LINK, so there is no issue. I have attached a patch which fixes this (off of the old head), and allows all tests to pass on both machines. The debug output on the line right below the one I changed suggests this is the right thing to do, although I don't know the full consequences of it.
(file #17557)
|
Tue 24 Feb 2009 09:35:20 AM UTC, comment #2:
Yes, the system has a stat()able /etc/passwd file. That's not the issue.
Secondly, the problem is reproduceable by hand, and only ftsfind is affected.
Now for the interesting part:
It turns out the test works on a ubuntu machine. More interestingly, a clean install of gentoo within a chroot on the ubuntu machine also allows the tests to be passed.
On the flip side, I can't get the tests to work in any chroot (clean gentoo or ubuntu) on the original test machine. Also the test fails on yet a third gentoo machine. Thus, I suspect there is something which is not playing nicely with ftsfind in a default configured gentoo kernel (2.6.27-gentoo-r8). I have yet to get the motivation to figure out what specifically the issue could be. If there are any other tests you had in mind to determine if this is a gentoo specific issue or something in findutils, I'd be happy to look into it. Like I said before, something in the Nov 30 commit seems to expose the issue.
|
Mon 19 Jan 2009 08:48:49 PM UTC, original submission:
find -H seems to incorrectly follow symbolic links in some cases, as revealed by the test output:
FAIL: posix-h.new-O0, standard output differs from the expected result:
--- find.out 2009-01-19 12:44:00.000000000 -0800
+++ cmp.out 2009-01-19 12:44:00.000000000 -0800
@@ -1,5 +1,5 @@
H1: d 0 tmp
H1: f 0 tmp/LINK
-H1: f 1 tmp/LINK
H1: l 0 tmp/BROKEN
H1: l 1 tmp/BROKEN
+H1: l 1 tmp/LINK
child process exited abnormally
FAIL: posix-h.new-O1, standard output differs from the expected result:
--- find.out 2009-01-19 12:44:00.000000000 -0800
+++ cmp.out 2009-01-19 12:44:00.000000000 -0800
@@ -1,5 +1,5 @@
H1: d 0 tmp
H1: f 0 tmp/LINK
-H1: f 1 tmp/LINK
H1: l 0 tmp/BROKEN
H1: l 1 tmp/BROKEN
+H1: l 1 tmp/LINK
child process exited abnormally
FAIL: posix-h.new-O2, standard output differs from the expected result:
--- find.out 2009-01-19 12:44:00.000000000 -0800
+++ cmp.out 2009-01-19 12:44:00.000000000 -0800
@@ -1,5 +1,5 @@
H1: d 0 tmp
H1: f 0 tmp/LINK
-H1: f 1 tmp/LINK
H1: l 0 tmp/BROKEN
H1: l 1 tmp/BROKEN
+H1: l 1 tmp/LINK
child process exited abnormally
FAIL: posix-h.new-O3, standard output differs from the expected result:
--- find.out 2009-01-19 12:44:00.000000000 -0800
+++ cmp.out 2009-01-19 12:44:00.000000000 -0800
@@ -1,5 +1,5 @@
H1: d 0 tmp
H1: f 0 tmp/LINK
-H1: f 1 tmp/LINK
H1: l 0 tmp/BROKEN
H1: l 1 tmp/BROKEN
+H1: l 1 tmp/LINK
child process exited abnormally
The failure seems to somehow be caused by the Nov 30 commit:
http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=acb82fe44369c108b43ec3e805aa94bf28352d0a
Undoing this commit seems to fix the test failures.
Reference: http://bugs.gentoo.org/show_bug.cgi?id=253119
|