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.
