bug#18896: regressions in coreutils 8.23 on Yosemite

[Pádraig Brady]

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?

> % 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.