[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #25359] files/testsuite/find.gnu/posix-h.exp tests fail v4.5.3
From: |
Nick Fortino |
Subject: |
[bug #25359] files/testsuite/find.gnu/posix-h.exp tests fail v4.5.3 |
Date: |
Mon, 02 Mar 2009 04:31:41 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.6) Gecko/2009022418 Gentoo Firefox/3.0.6 |
Follow-up Comment #5, bug #25359 (project findutils):
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 %pn"
Starting program: /home/nfortino/findutils/find/find -H tmp/LINK tmp/BROKEN
tmp -printf "H1: %y %d %pn"
[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)
_______________________________________________________
Additional Item Attachment:
File name: findutils.setdepth.patch Size:0 KB
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?25359>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/