[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65324: "make check" hangs on NetBSD 9.3
From: |
Michael Albinus |
Subject: |
bug#65324: "make check" hangs on NetBSD 9.3 |
Date: |
Thu, 14 Sep 2023 14:51:41 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.
- bug#65324: "make check" hangs on NetBSD 9.3, (continued)
- bug#65324: "make check" hangs on NetBSD 9.3, Bruno Haible, 2023/09/04
- bug#65324: "make check" hangs on NetBSD 9.3, Michael Albinus, 2023/09/04
- bug#65324: "make check" hangs on NetBSD 9.3, Bruno Haible, 2023/09/04
- bug#65324: "make check" hangs on NetBSD 9.3, Michael Albinus, 2023/09/05
- bug#65324: "make check" hangs on NetBSD 9.3, Michael Albinus, 2023/09/11
- bug#65324: "make check" hangs on NetBSD 9.3, Bruno Haible, 2023/09/12
- bug#65324: "make check" hangs on NetBSD 9.3, Michael Albinus, 2023/09/12
- bug#65324: "make check" hangs on NetBSD 9.3, Bruno Haible, 2023/09/12
- bug#65324: "make check" hangs on NetBSD 9.3, Michael Albinus, 2023/09/13
- bug#65324: "make check" hangs on NetBSD 9.3, Bruno Haible, 2023/09/13
- bug#65324: "make check" hangs on NetBSD 9.3,
Michael Albinus <=
- bug#65324: "make check" hangs on NetBSD 9.3, Michael Albinus, 2023/09/22