bugfindutils - Bugs: bug #25359, ...

 
 

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

Submitted by:  None
Submitted on:  Mon 19 Jan 2009 08:48:49 PM UTC  
 
Category: findSeverity: 3 - Normal
Item Group: Wrong resultStatus: Fixed
Privacy: PublicAssigned to: James Youngman <jay>
Originator Name: Nick FortinoOriginator Email: -unavailable-
Open/Closed: ClosedRelease: 4.5.3
Fixed Release: 4.5.4

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Wed 04 Mar 2009 12:03:16 AM UTC, comment #6:

I agree that your suggestion is better and so I've made a change along the lines you suggested. I'm attaching a diff representing the new approach, but the diff I actually applied is longer since it needs to revert part of my previous change too.

(file #17576)

James Youngman <jay>
Project AdministratorIn charge of this item.
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)

Nick Fortino <nfortino>
Mon 02 Mar 2009 02:01:32 AM UTC, comment #4:

I believe the attached patch fixes the problem.

(file #17555, file #17556)

James Youngman <jay>
Project AdministratorIn charge of this item.
Mon 02 Mar 2009 12:14:49 AM UTC, comment #3:

The patch at http://bugs.gentoo.org/show_bug.cgi?id=253119 does not totally reverse the findutils patch - specifically, it doesn't change the version of gnulib that findutils is built with.

So on the basis of that, it seems to me that while xstat points to the correct target function for determining the correct value for %y, the data that comes back in fts_statp->st_mode is wrong for that when the -H option is in effect.

I wasn't able to reproduce this problem on my local system as it doesn't set d_type for the directory in which I was running the regression tests (though it does support fractional-second timestamps).

James Youngman <jay>
Project AdministratorIn charge of this item.
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.

Nick Fortino <nfortino>
Sat 21 Feb 2009 11:44:38 PM UTC, comment #1:

Does the system under test have a stat()able /etc/passwd file? Can you reproduce the problem manually? (This test passes for me here, obviously, or 4.5.3 would never have been released). Does the problem apply only to ftsfind, or is oldfind also affected?

James Youngman <jay>
Project AdministratorIn charge of this item.
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

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by nfortino (Posted a comment)
  • -unavailable- added by jay (Posted a comment)
  • -unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 06 Jul 2009 10:48:53 PM UTCjayOpen/ClosedOpen=>Closed
      Fixed ReleaseNone=>4.5.4
    Wed 04 Mar 2009 12:03:16 AM UTCjayAttached File-=>Added nick-fortino-inspired-fix.patch, #17576
    Mon 02 Mar 2009 04:31:39 AM UTCnfortinoAttached File-=>Added findutils.setdepth.patch, #17557
    Mon 02 Mar 2009 02:01:32 AM UTCjayAttached File-=>Added 0001-Fix-Savannah-bug-25359.patch, #17555
      Attached File-=>Added 0002-Indicate-which-the-first-fixed-version-of-findutils.patch, #17556
      StatusNone=>Fixed
      Assigned toNone=>jay

    Back to the top


    Powered by Savane 3.1-cleanup1