bug#28506: coreutils 8.28 test suite hangs on APFS filesystem

[Pádraig Brady]

On 20/09/17 23:02, Jim Meyering wrote:
> On Wed, Sep 20, 2017 at 10:20 PM, Pádraig Brady <address@hidden> wrote:
>> On 18/09/17 18:07, Jack Howarth wrote:
>>> On Mon, Sep 18, 2017 at 7:40 PM, Jim Meyering <address@hidden> wrote:
>>>
>>>> On Mon, Sep 18, 2017 at 4:26 PM, Jack Howarth
>>>> <address@hidden> wrote:
>>>>> On Mon, Sep 18, 2017 at 5:08 PM, Jim Meyering <address@hidden> wrote:
>>>> ...
>>>>>> Is there any chance your failing test was via a python2 framework? I'm
>>>>>> asking (on Pádraig's behalf) because there is a known problem whereby
>>>>>> SIGPIPE is mishandled in that case, and that might explain this
>>>>>> failure, since the data-generation phase relies on SIGPIPE killing
>>>>>> this test's "yes" command.
>>>>>
>>>>> I doubt it as the hang doesn't happen under 10.13 when run on a JHFS
>>>>> formatted volume.
>>>>
>>>> How did you run the tests?
>>>>
>>>
>>> Actually, I forgot to mention that the coreutils test suite hang only
>>> occurred on the APFS volumes when the coreutils built against the gettext
>>> and libiconv from fink. A build outside of fink which didn't build against
>>> those packages didn't show the hang in the coreutils test suite. The fink
>>> gettext and libiconv packages that I am using are those from...
>>>
>>> https://sourceforge.net/p/fink/package-submissions/4955/
>>>
>>> and
>>>
>>> https://sourceforge.net/p/fink/package-submissions/5004/
>>>
>>> which are both patched for the format string strictness in High Sierra. I
>>> found that using --disable-nls in configuring coreutils was insufficient to
>>> suppress the test suite hang which I assume is due to the presence of...
>>>
>>> #define HAVE_LIBINTL_H 1
>>>
>>> in the generated ./lib/config.h
>>>
>>> despite the presence of...
>>>
>>> /* #undef HAVE_DCGETTEXT */
>>> /* #undef HAVE_GETTEXT */
>>>
>>> when --disable-nls is used so it still could be a Unicode related change in
>>> APFS, no?
>>>       Jack
>>
>> The libintl bit reminded me of 
>> https://lists.gnu.org/archive/html/bug-gnulib/2014-10/msg00014.html
>> I.E. on OSX enabling those libs creates implicit threads I think.
>> Perhaps that's messing with SIGPIPE handling and only the implicit
>> thread gets it, thus not killing the main yes(1) thread.
>> However the yes(1) is also protected with a timeout(1) call.
>> Perhaps timeout(1) is a silent noop. We should support OSX through 
>> DYLD_INSERT_LIBRARIES,
>> but perhaps there is something preventing that on your system?
>> But then would the timeout tests fail. Could you check the timeout tests 
>> with:
>>
>>   make SUBDIRS=. TESTS=tests/misc/filter.sh check
>>
>> In any case we should protect calls to timeout(1) to ensure it's supported.
>> The attached does that at least.
> 
> Good idea.
> Do you think there should be a syntax-check rule to ensure that any
> timeout-using test first calls require_timeout_? This makes me wonder
> if we should make timeout a function that does that job (the first
> time only), and then exec's the real timeout command.

Yes that would be better.
Also functions for sleep, printf etc. would be useful in
avoiding the need for explicit env and giving greater test coverage.
I'll work on that