[bug #25359] files/testsuite/find.gnu/posix-h.exp tests fail v4.5.3

[Nick Fortino]

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/