bugfindutils - Bugs: bug #25359, ...

 
 

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

Submitter:  None
Submitted:  Mon 19 Jan 2009 08:48:49 PM UTC
   
 
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Fixed
Privacy:  Public Assigned to:  jay
Originator Name:  Nick Fortino Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.5.3
Fixed Release:  4.5.4
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group administrator
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 Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-07-06 jay Open/ClosedOpen Closed
        Fixed ReleaseNone 4.5.4
    2009-03-04 jay Attached File- Added nick-fortino-inspired-fix.patch, #17576
    2009-03-02 nfortino Attached File- Added findutils.setdepth.patch, #17557
    2009-03-02 jay Attached 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.13-d3ae.
    Corresponding source code