bug#18896: regressions in coreutils 8.23 on Yosemite

[Jack Howarth]

On Fri, Oct 31, 2014 at 04:03:43PM +0000, Pádraig Brady wrote:
> On 10/31/2014 03:41 PM, Jack Howarth wrote:
> > On Fri, Oct 31, 2014 at 03:56:06AM +0000, Pádraig Brady wrote:
> >> On 10/31/2014 03:30 AM, Jack Howarth wrote:
> >>> On Fri, Oct 31, 2014 at 02:29:05AM +0000, Pádraig Brady wrote:
> >>>>
> >>>> So linkat() is now available but doesn't support hardlinks to symlinks
> >>>> contrary to the POSIX spec. So it would be best we consider linkat()
> >>>> unavailable, which can be done manually like:
> >>>>
> >>>>   ac_cv_func_linkat=no ./configure
> >>>>
> >>>> We'll have to augment the gnulib linkat check to actually check
> >>>> that linkat() works, rather than just being available.
> >>>
> >>> Passing ac_cv_func_linkat=no to configure and using your attached patch
> >>> results in a large number of failures on x86_64-apple-darwin14.
> >>
> >> Good that's better. coreutils tests have passed, and you're getting
> >> to gnulib issues below.
> >>
> >>
> >>> FAIL: test-readlinkat
> >>> =====================
> >>> ./test-readlink.h:71: assertion 'func (BASE "link2/", buf, sizeof buf) == 
> >>> -1' failed
> >>>
> >>> FAIL: test-symlinkat
> >>> ====================
> >>> ./test-symlink.h:83: assertion 'func (BASE "nowhere", BASE "link1/") == 
> >>> -1' failed
> >>>
> >>> FAIL: test-unlinkat
> >>> ===================
> >>> ./test-unlink.h:49: assertion 'func ("..") == -1' failed
> >>> This is indicating these system functions are succeeding (or failing with 
> >>> a different return value)
> >> while their non "at" equivalents are failing as expected.  That's 
> >> surprising.
> >> It would be useful to determine (with printf/gdb) the return value and 
> >> errno in the above tests.
> > 
> > Interestingly some of these asserts seem to be suppressed when I run the 
> > failing testcases through
> > lldb or gdb.
> > 
> > % sudo lldb ./test-fdutimensat
> > (lldb) target create "./test-fdutimensat"
> > Current executable set to './test-fdutimensat' (x86_64).
> > (lldb) r
> > Process 26490 launched: './test-fdutimensat' (x86_64)
> > Process 26490 exited with status = 0 (0x00000000) 
> > (lldb) 
> 
> Weird, timing issue?

Normally that sort of thing occurs when the crash is due to a bad memory access 
which a
debugger suppresses. At least in my experience on darwin.

> 
> > % sudo lldb ./test-unlinkat
> > (lldb) target create "./test-unlinkat"
> > Current executable set to './test-unlinkat' (x86_64).
> > (lldb) r
> > Process 51535 launched: './test-unlinkat' (x86_64)
> > Process 51535 exited with status = 0 (0x00000000) 
> > (lldb)
> 
> Surprising.
> 
> > whereas others aren't...
> > 
> > % sudo lldb ./test-readlinkat
> > (lldb) target create "./test-readlinkat"
> > Current executable set to './test-readlinkat' (x86_64).
> > (lldb) r
> > Process 51522 launched: './test-readlinkat' (x86_64)
> > ./test-readlink.h:71: assertion 'func (BASE "link2/", buf, sizeof buf) == 
> > -1' failed
> > Process 51522 stopped
> 
> This one is succeeding unexpectedly (I'm guessing that readlinkat() is 
> returning 0 here?)
> Eric might have more insight into whether we should relax this test.
> 
> > h% sudo lldb ./test-symlinkat
> > (lldb) target create "./test-symlinkat"
> > Current executable set to './test-symlinkat' (x86_64).
> > (lldb) r
> > Process 51529 launched: './test-symlinkat' (x86_64)
> > ./test-symlink.h:83: assertion 'func (BASE "nowhere", BASE "link1/") == -1' 
> > failed
> > Process 51529 stopped
> > * thread #1: tid = 0x74d1b5, 0x00007fff962cd282 
> > libsystem_kernel.dylib`__pthread_kill + 10, queue = 
> > 'com.apple.main-thread', stop reason = signal SIGABRT
> >     frame #0: 0x00007fff962cd282 libsystem_kernel.dylib`__pthread_kill + 10
> > libsystem_kernel.dylib`__pthread_kill + 10:
> > -> 0x7fff962cd282:  jae    0x7fff962cd28c            ; __pthread_kill + 20
> >    0x7fff962cd284:  movq   %rax, %rdi
> >    0x7fff962cd287:  jmp    0x7fff962c8ca3            ; cerror_nocancel
> >    0x7fff962cd28c:  retq   
> > (lldb) bt
> > * thread #1: tid = 0x74d1b5, 0x00007fff962cd282 
> > libsystem_kernel.dylib`__pthread_kill + 10, queue = 
> > 'com.apple.main-thread', stop reason = signal SIGABRT
> >   * frame #0: 0x00007fff962cd282 libsystem_kernel.dylib`__pthread_kill + 10
> >     frame #1: 0x00007fff8ffc44c3 libsystem_pthread.dylib`pthread_kill + 90
> >     frame #2: 0x00007fff8bfe7b73 libsystem_c.dylib`abort + 129
> >     frame #3: 0x0000000100001293 
> > test-symlinkat`test_symlink(print=<unavailable>, func=<unavailable>) + 2211 
> > at test-symlink.h:43
> >     frame #4: 0x0000000100000849 test-symlinkat`main + 169 at 
> > test-symlinkat.c:79
> >     frame #5: 0x00007fff999935c9 libdyld.dylib`start + 1
> >     frame #6: 0x00007fff999935c9 libdyld.dylib`start + 1
> > (lldb) 
> >
> > where the error is at...
> > 
> > static int
> > test_symlink (int (*func) (char const *, char const *), bool print)
> > {
> >   if (func ("nowhere", BASE "link1"))
> >     {
> >       if (print)
> >         fputs ("skipping test: symlinks not supported on this file 
> > system\n",
> >                stderr);
> >       return 77;
> >     }
> > 
> >   /* Some systems allow the creation of 0-length symlinks as a synonym
> >      for "."; but most reject it.  */
> >   {
> >     int status;
> >     errno = 0;
> >     status = func ("", BASE "link2");
> >     if (status == -1)
> >       ASSERT (errno == ENOENT || errno == EINVAL);     <<<<<<<<<--------- 
> > crash on Yosemite
> >     else
> >       {
> >         ASSERT (status == 0);
> >         ASSERT (unlink (BASE "link2") == 0);
> >       }
> >   }
> 
> There is a mismatch between the line numbers reported by ASSERT() and lldb
> which may be due to the way the header is being included.
> Anyway it would be best to step through (over the functions) the test
> noting the returns and errno at the failing step.
> 
> thanks again,
> Pádraig.