This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: misc/tst-ttyname time outs
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, nd <nd at arm dot com>, Luke Shumaker <lukeshu at lukeshu dot com>
- Date: Wed, 2 Jan 2019 10:02:45 -0500
- Subject: Re: misc/tst-ttyname time outs
- References: <cd4d6b0a-3484-fdd7-add1-a9102560a15d@arm.com> <87a7kj2k0i.fsf@oldenburg2.str.redhat.com>
On 1/2/19 9:48 AM, Florian Weimer wrote:
> * Szabolcs Nagy:
>
>> in run_chroot_tests the following loop time outs for me:
>>
>> /* keep creating PTYs until we we get a name collision */
>> while (stat (slavename, &st) < 0)
>> posix_openpt (O_RDWR|O_NOCTTY|O_NONBLOCK);
>>
>> it seems posix_openpt can fail with EMFILE or ENOSPC in the
>> loop and then it never finishes.
>>
>> example strace:
>> [pid 24510] newfstatat(AT_FDCWD, "/dev/pts/1789", 0xffffdd528fe0, 0) = -1 ENOENT (No such file or directory)
>> [pid 24510] openat(AT_FDCWD, "/dev/ptmx", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOSPC (No space left on device)
>> [pid 24510] newfstatat(AT_FDCWD, "/dev/pts/1789", 0xffffdd528fe0, 0) = -1 ENOENT (No such file or directory)
>> [pid 24510] openat(AT_FDCWD, "/dev/ptmx", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOSPC (No space left on device)
>> [pid 24510] newfstatat(AT_FDCWD, "/dev/pts/1789", 0xffffdd528fe0, 0) = -1 ENOENT (No such file or directory)
>> ...
>>
>> i'm not sure what can cause such failures, but it happens
>> regularly on the aarch64 build bot instance recently, let
>> me know if somebody knows how to make that loop or the
>> runtime environment more reliable.
>
> I think we should detect that posix_openpt fails and treat ENOSPC,
> EMFILE, ENFILE as unsupported, along with an error message that we could
> not create a PTY collision for slavename. Other error should result in
> a hard failure.
>
> I can write a patch if you are able to test it.
I agree that's the best option. You should just checkin a fix, it's
obvious that if we're failing with ENOSPC, EMFILE, or ENFILE that we're
unable to complete the test.
However, I would add another requirement:
* Print an message indicating possible ways in which this can be fixed
to work.
For example, should we try to determine what needs fixing and print an
appropriate informative message?
--
Cheers,
Carlos.