all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 65324@debbugs.gnu.org, Stefan Kangas <stefankangas@gmail.com>
Subject: bug#65324: "make check" hangs on NetBSD 9.3
Date: Wed, 13 Sep 2023 21:17:25 +0200	[thread overview]
Message-ID: <2299121.ZuhQCC13oI@nimes> (raw)
In-Reply-To: <87fs3ip2eu.fsf@gmx.de>

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

Michael Albinus wrote:
> So I have rewitten it, and pushed it to Emacs master.
> ...
> So I exclude this special "ln -sf" call for NetBSD, such longuish file
> names shouldn't happen in the wild (I hope). See the reworked patch for
> tramp-tests.el.

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

> 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.
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

> 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.
  - tramp seems not only to fail in this case, but to go into an endless loop,
    which is much much worse.

Btw, I know that passing long commands through pipes is hard to implement.
A frequent mistake - that leads to endlessly hanging processes - is to leave
a file descriptor open in both the parent and the child process, when it
should only be open in one of the two.

Bruno

[-- Attachment #2: netbsd93-tramp-logs.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 101853 bytes --]

  reply	other threads:[~2023-09-13 19:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-15 22:02 bug#65324: "make check" hangs on NetBSD 9.3 Bruno Haible
2023-09-01 20:23 ` Stefan Kangas
2023-09-02 11:24   ` Michael Albinus
2023-09-02 11:33     ` Bruno Haible
2023-09-02 11:54       ` Michael Albinus
2023-09-02 12:16         ` Bruno Haible
2023-09-02 14:08           ` Michael Albinus
2023-09-02 15:25             ` Bruno Haible
2023-09-02 16:30               ` Michael Albinus
2023-09-02 17:55                 ` Bruno Haible
2023-09-04  9:52                   ` Michael Albinus
2023-09-04 10:19                     ` Bruno Haible
2023-09-04 10:28                       ` Michael Albinus
2023-09-04 10:39                         ` Bruno Haible
2023-09-05 17:56                           ` Michael Albinus
2023-09-11 12:26                             ` Michael Albinus
2023-09-12 14:31                               ` Bruno Haible
2023-09-12 20:12                                 ` Michael Albinus
2023-09-12 23:03                                   ` Bruno Haible
2023-09-13 14:34                                     ` Michael Albinus
2023-09-13 19:17                                       ` Bruno Haible [this message]
2023-09-14 12:51                                         ` Michael Albinus
2023-09-22 18:06                                           ` Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2299121.ZuhQCC13oI@nimes \
    --to=bruno@clisp.org \
    --cc=65324@debbugs.gnu.org \
    --cc=michael.albinus@gmx.de \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.