bug#65324: "make check" hangs on NetBSD 9.3

[Michael Albinus <michael.albinus@gmx.de>]

Bruno Haible <bruno@clisp.org> writes:

Hi Bruno,

> With these two new files, the tramp part of "gmake check" terminates.
> Find attached the log files.

Thanks. I've pushed the fix to Emacs master.

>> And NetBSD has restricted ressources, for example it
>> reports PIPE_BUF being 512, where other systems report 4096 ...
>
> If your code and tests depend on the value of PIPE_BUF, that explains it.

No, this special case doesn't depend on PIPE_BUF I believe. I've used
PIPE_BUF as an example to compare NetBSD with Linux, because I have seen
it in the traces, and because it it shows the more limited ressources on
NetBSD.

> Whereas the maximum command line length (according to the libtool configure
> test) is:
>   checking the maximum length of command line arguments... 196608
>
> The PIPE_BUF in POSIX [1] can be as low as 512 [2]. Here are the values
> on various platforms:
>   - 512 on macOS, FreeBSD, NetBSD, OpenBSD, MirBSD, native Windows.
>   - 4 KiB on Linux, OSF/1, Cygwin, Haiku.
>   - 5 KiB on Solaris.
>   - 8 KiB on HP-UX, Plan9.
>   - 10 KiB on IRIX.
>   - 32 KiB on AIX, Minix.
>
> [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html
> [2] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html

Thanks to the explanation, much appreciated!

>> such longuish file names shouldn't happen in the wild (I hope).
>
> But the problem is:
>   - It's not only NetBSD. It's all *BSDs that have a PIPE_BUF value of 512.

I have an OpenBSD VM as test system, and it didn't show this error. And
I didn't get a similar bug report yet from other users, for example
users with macOS.

But as said, I don't believe it is a PIPE_BUF problem.

>   - tramp seems not only to fail in this case, but to go into an endless loop,
>     which is much much worse.

Yes. Tramp waits for a response from remote, which didn't arrive. One
could thing about a timeout, but since Tramp sends arbitrary commands
over arbitrary slow lines to arbitrary slow machines, I don't know of a
proper value of such a timeout.

Well, I believe we have nailed it for *this* bug report. OK for you if I
close it?

> Bruno

Best regards, Michael.