* Hang in E01 due to zpty on OpenBSD @ 2022-04-03 21:42 Matthew Martin 2022-04-04 1:04 ` Bart Schaefer 2022-04-04 2:39 ` Jun T 0 siblings, 2 replies; 15+ messages in thread From: Matthew Martin @ 2022-04-03 21:42 UTC (permalink / raw) To: zsh-workers E01 hangs on OpenBSD-current when run as the _pbuild user. The line that hangs is L1435 zpty subshell $ZTST_testdir/../Src/zsh -f +Z which is because the read call in Modules/zpty.c L472 ret = read(master, &syncch, 1); never returns. I believe this is because the forked child fails to open the corresponding tty when get_pty is called on 362 and the child exits. I assume the EPERM on open is an OpenBSD bug, but zsh should probably not hang either. I'd appreciate if anyone could confirm the below is an accurate minimal reproducer to report to OpenBSD. #include <err.h> #include <fcntl.h> #include <stdio.h> #include <string.h> #include <unistd.h> static int get_pty(char *path) { const char char1[] = "pqrstuvwxyzPQRST"; const char char2[] = "0123456789" "abcdefghijklmnopqrstuvwxyz" "ABCDEFGHIJKLMNOPQRSTUVWXYZ"; const char *p1, *p2; int fd; strcpy(path, "/dev/ptyxx"); for (p1 = char1; *p1; p1++) { path[8] = *p1; for (p2 = char2; *p2; p2++) { path[9] = *p2; if ((fd = open(path, O_RDWR|O_NOCTTY)) >= 0) { return fd; } } } return -1; } int main() { char path[11]; int ptyfd, ttyfd; if ((ptyfd = get_pty(path)) == -1) { err(1, "get_pty"); } printf("%d: %s\n", ptyfd, path); path[5] = 't'; if ((ttyfd = open(path, O_RDWR|O_NOCTTY)) == -1) { err(1, "open"); } printf("%d: %s\n", ttyfd, path); } ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Hang in E01 due to zpty on OpenBSD 2022-04-03 21:42 Hang in E01 due to zpty on OpenBSD Matthew Martin @ 2022-04-04 1:04 ` Bart Schaefer 2022-04-04 2:34 ` Matthew Martin 2022-04-04 2:39 ` Jun T 1 sibling, 1 reply; 15+ messages in thread From: Bart Schaefer @ 2022-04-04 1:04 UTC (permalink / raw) To: Zsh hackers list On Sun, Apr 3, 2022 at 2:43 PM Matthew Martin <phy1729@gmail.com> wrote: > > I assume the EPERM on open is an OpenBSD bug, but zsh should probably > not hang either. I'm not sure what could be done about this from the zsh code. The only reasonable assumption for the pty master-side reader is that the slave-slide will become closed upon an error and the read will fail. Using a non-blocking read would defeat the purpose. I suppose we could skip the test on OpenBSD, but there are a bunch of later tests that rely on zpty functioning. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Hang in E01 due to zpty on OpenBSD 2022-04-04 1:04 ` Bart Schaefer @ 2022-04-04 2:34 ` Matthew Martin 2022-04-04 3:49 ` Matthew Martin 0 siblings, 1 reply; 15+ messages in thread From: Matthew Martin @ 2022-04-04 2:34 UTC (permalink / raw) To: zsh-workers On Sun, Apr 03, 2022 at 06:04:30PM -0700, Bart Schaefer wrote: > On Sun, Apr 3, 2022 at 2:43 PM Matthew Martin <phy1729@gmail.com> wrote: > > > > I assume the EPERM on open is an OpenBSD bug, but zsh should probably > > not hang either. > > I'm not sure what could be done about this from the zsh code. The > only reasonable assumption for the pty master-side reader is that the > slave-slide will become closed upon an error and the read will fail. > Using a non-blocking read would defeat the purpose. The only reasonable thing I can come up with is open both pty and tty on the first call to get_pty, so the second call can't fail. The tests pass when I use openpty; though since that's in libutil and I didn't immedietly see a way to link that in, there's a terrible work around with dlopen/dlsym. I have no intention to commit this. I've sent a mail to OpenBSD. I don't think this should block the release. Worst case there will be a patch in the port that can be upstreamed by the next release. diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c index dfd2a2a7a..3f21c2b89 100644 --- a/Src/Modules/zpty.c +++ b/Src/Modules/zpty.c @@ -37,6 +37,12 @@ #endif #endif +#ifdef __OpenBSD__ +#include <dlfcn.h> +#include <termios.h> +#include <util.h> +#endif + /* The number of bytes we normally read when given no pattern and the * upper bound on the number of bytes we read (even if we are give a * pattern). */ @@ -161,8 +167,38 @@ getptycmd(char *name) return NULL; } -/* posix_openpt() seems to have some problem on OpenBSD */ -#if defined(USE_DEV_PTMX) && !defined(__OpenBSD__) +#if defined(__OpenBSD__) + +static int +get_pty(int master, int *retfd) +{ + static int mfd, sfd; + + if (master) { + void *handle; + int (*openpty)(int *, int *, char *, struct termios *, struct winsize *); + + if ((handle = dlopen("libutil.so", 0)) == NULL) { + return 1; + } + if ((openpty = dlsym(handle, "openpty")) == NULL) { + dlclose(handle); + return 1; + } + if (openpty(&mfd, &sfd, NULL, NULL, NULL) == -1) { + dlclose(handle); + return 1; + } + dlclose(handle); + *retfd = mfd; + return 0; + } + + *retfd = sfd; + return 0; +} + +#elif defined(USE_DEV_PTMX) #ifdef HAVE_SYS_STROPTS_H #include <sys/stropts.h> @@ -261,12 +297,7 @@ get_pty(int master, int *retfd) #elif defined(__FreeBSD__) || defined(__DragonFly__) static char char1[] = "pqrsPQRS"; static char char2[] = "0123456789abcdefghijklmnopqrstuv"; -#elif defined(__OpenBSD__) - static char char1[] = "pqrstuvwxyzPQRST"; - static char char2[] = "0123456789" - "abcdefghijklmnopqrstuvwxyz" - "ABCDEFGHIJKLMNOPQRSTUVWXYZ"; -#else /* __FreeBSD__ || __DragonFly__ || __OpenBSD*/ +#else /* __FreeBSD__ || __DragonFly__ */ static char char1[] = "pqrstuvwxyzPQRST"; static char char2[] = "0123456789abcdef"; #endif ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Hang in E01 due to zpty on OpenBSD 2022-04-04 2:34 ` Matthew Martin @ 2022-04-04 3:49 ` Matthew Martin 2022-04-04 8:34 ` Jun T 0 siblings, 1 reply; 15+ messages in thread From: Matthew Martin @ 2022-04-04 3:49 UTC (permalink / raw) To: zsh-workers On Sun, Apr 03, 2022 at 09:34:07PM -0500, Matthew Martin wrote: > The tests pass when I use openpty; though since that's in libutil and > I didn't immedietly see a way to link that in, there's a terrible work > around with dlopen/dlsym. I have no intention to commit this. OpenBSD has gutted the pty route and strongly prefers openpty over posix_openpt. Is there a correct way link the zpty module against libutil? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Hang in E01 due to zpty on OpenBSD 2022-04-04 3:49 ` Matthew Martin @ 2022-04-04 8:34 ` Jun T 2022-04-04 11:21 ` Mikael Magnusson 2022-04-04 13:16 ` Matthew Martin 0 siblings, 2 replies; 15+ messages in thread From: Jun T @ 2022-04-04 8:34 UTC (permalink / raw) To: zsh-workers > 2022/04/04 12:49, Matthew Martin <phy1729@gmail.com> wrote: > > OpenBSD has gutted the pty route and strongly prefers openpty over > posix_openpt. Is there a correct way link the zpty module against > libutil? Please try the following patch. Replace the pattern (in configure.ac) openbsd*) by openbsd7*) or such if openpty() should be used only on specific versions of OpenBSD. diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c index dfd2a2a7a..cdab1d8e1 100644 --- a/Src/Modules/zpty.c +++ b/Src/Modules/zpty.c @@ -249,6 +249,28 @@ get_pty(int master, int *retfd) return 0; } +/* openpty() is prefered on OpenBSD */ +#elif defined(__OpenBSD__) && defined(HAVE_OPENPTY) + +#include <util.h> + +static int +get_pty(int master, int *retfd) +{ + static int mfd, sfd; + + if (master) { + if (openpty(&mfd, &sfd, NULL, NULL, NULL) == -1) + return 1; + + *retfd = mfd; + return 0; + } + + *retfd = sfd; + return 0; +} + #else /* No /dev/ptmx or no pt functions */ static int diff --git a/configure.ac b/configure.ac index 8bba78c56..6aae71300 100644 --- a/configure.ac +++ b/configure.ac @@ -2441,6 +2441,18 @@ int ptsname();]], [[]])],[ac_cv_use_dev_ptmx=no],[ac_cv_use_dev_ptmx=yes])]) fi fi +dnl On (some) OpenBSD, it seems openpty() is the only reliable way to get pty. +AH_TEMPLATE([HAVE_OPENPTY], +[Define to 1 if openpt() is available on OpenBSD]) +case "$host_os" in + openbsd*) + AC_SEARCH_LIBS(openpty, util) + if test x$ac_cv_search_openpty != xno; then + AC_DEFINE(HAVE_OPENPTY) + fi + ;; +esac + dnl ----------------- dnl multibyte support dnl ----------------- ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Hang in E01 due to zpty on OpenBSD 2022-04-04 8:34 ` Jun T @ 2022-04-04 11:21 ` Mikael Magnusson 2022-04-04 13:16 ` Matthew Martin 1 sibling, 0 replies; 15+ messages in thread From: Mikael Magnusson @ 2022-04-04 11:21 UTC (permalink / raw) To: Jun T; +Cc: zsh-workers On 4/4/22, Jun T <takimoto-j@kba.biglobe.ne.jp> wrote: > > Please try the following patch. > > diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c > index dfd2a2a7a..cdab1d8e1 100644 > --- a/Src/Modules/zpty.c > +++ b/Src/Modules/zpty.c > diff --git a/configure.ac b/configure.ac > index 8bba78c56..6aae71300 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2441,6 +2441,18 @@ int ptsname();]], > [[]])],[ac_cv_use_dev_ptmx=no],[ac_cv_use_dev_ptmx=yes])]) > fi > fi > > +dnl On (some) OpenBSD, it seems openpty() is the only reliable way to get > pty. > +AH_TEMPLATE([HAVE_OPENPTY], > +[Define to 1 if openpt() is available on OpenBSD]) Missing y here in openpty. -- Mikael Magnusson ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Hang in E01 due to zpty on OpenBSD 2022-04-04 8:34 ` Jun T 2022-04-04 11:21 ` Mikael Magnusson @ 2022-04-04 13:16 ` Matthew Martin 2022-04-06 5:48 ` Jun T 1 sibling, 1 reply; 15+ messages in thread From: Matthew Martin @ 2022-04-04 13:16 UTC (permalink / raw) To: zsh-workers On Mon, Apr 04, 2022 at 05:34:09PM +0900, Jun T wrote: > > > 2022/04/04 12:49, Matthew Martin <phy1729@gmail.com> wrote: > > > > OpenBSD has gutted the pty route and strongly prefers openpty over > > posix_openpt. Is there a correct way link the zpty module against > > libutil? > > Please try the following patch. I had tried a similar patch, but since openpty is in libutil, that needs to be linked in which is why I have the dlopen/dlsym calls in 49980. > Replace the pattern (in configure.ac) > openbsd*) > by > openbsd7*) > or such if openpty() should be used only on specific versions of OpenBSD. I would only support OpenBSD-current unless anyone objects. Each release gets a corresponding snapshot of the ports tree and then only security updates are accepted for that version. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Hang in E01 due to zpty on OpenBSD 2022-04-04 13:16 ` Matthew Martin @ 2022-04-06 5:48 ` Jun T 2022-04-06 12:53 ` Matthew Martin 0 siblings, 1 reply; 15+ messages in thread From: Jun T @ 2022-04-06 5:48 UTC (permalink / raw) To: zsh-workers > 2022/04/04 22:16, Matthew Martin <phy1729@gmail.com> wrote: > > On Mon, Apr 04, 2022 at 05:34:09PM +0900, Jun T wrote: > >> Replace the pattern (in configure.ac) >> openbsd*) >> by >> openbsd7*) >> or such if openpty() should be used only on specific versions of OpenBSD. > > I would only support OpenBSD-current unless anyone objects We can't specify -current here. I've upgraded to OpenBSD-7.1 but still can't reproduce your problem. But since openpty() works fine on OpenBSD7.0/7.1, I will push the patch with 'openbsd7*)' (with Mikael's fix of typo) if there is no objection. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Hang in E01 due to zpty on OpenBSD 2022-04-06 5:48 ` Jun T @ 2022-04-06 12:53 ` Matthew Martin 2022-04-06 20:12 ` Bart Schaefer 2022-04-07 3:47 ` Jun T 0 siblings, 2 replies; 15+ messages in thread From: Matthew Martin @ 2022-04-06 12:53 UTC (permalink / raw) To: zsh-workers On Wed, Apr 06, 2022 at 02:48:00PM +0900, Jun T wrote: > > > 2022/04/04 22:16, Matthew Martin <phy1729@gmail.com> wrote: > > > > On Mon, Apr 04, 2022 at 05:34:09PM +0900, Jun T wrote: > > > >> Replace the pattern (in configure.ac) > >> openbsd*) > >> by > >> openbsd7*) > >> or such if openpty() should be used only on specific versions of OpenBSD. > > > > I would only support OpenBSD-current unless anyone objects > > We can't specify -current here. > I've upgraded to OpenBSD-7.1 but still can't reproduce your problem. > > But since openpty() works fine on OpenBSD7.0/7.1, I will push the patch > with 'openbsd7*)' (with Mikael's fix of typo) if there is no objection. I'd prefer something like the below where it's a feature test instead of an OS test. diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c index dfd2a2a7a..f4c95537d 100644 --- a/Src/Modules/zpty.c +++ b/Src/Modules/zpty.c @@ -37,6 +37,15 @@ #endif #endif +#ifdef HAVE_OPENPTY +#ifdef OPENPTY_REQUIRES_PTY +#include <pty.h> +#elif defined(OPENPTY_REQUIRES_UTIL) +#include <termios.h> +#include <util.h> +#endif +#endif + /* The number of bytes we normally read when given no pattern and the * upper bound on the number of bytes we read (even if we are give a * pattern). */ @@ -161,8 +170,26 @@ getptycmd(char *name) return NULL; } -/* posix_openpt() seems to have some problem on OpenBSD */ -#if defined(USE_DEV_PTMX) && !defined(__OpenBSD__) +#ifdef HAVE_OPENPTY + +static int +get_pty(int master, int *retfd) +{ + static int mfd, sfd; + + if (master) { + if (openpty(&mfd, &sfd, NULL, NULL, NULL) == -1) { + return 1; + } + *retfd = mfd; + return 0; + } + + *retfd = sfd; + return 0; +} + +#elifdef USE_DEV_PTMX #ifdef HAVE_SYS_STROPTS_H #include <sys/stropts.h> @@ -261,12 +288,7 @@ get_pty(int master, int *retfd) #elif defined(__FreeBSD__) || defined(__DragonFly__) static char char1[] = "pqrsPQRS"; static char char2[] = "0123456789abcdefghijklmnopqrstuv"; -#elif defined(__OpenBSD__) - static char char1[] = "pqrstuvwxyzPQRST"; - static char char2[] = "0123456789" - "abcdefghijklmnopqrstuvwxyz" - "ABCDEFGHIJKLMNOPQRSTUVWXYZ"; -#else /* __FreeBSD__ || __DragonFly__ || __OpenBSD*/ +#else /* __FreeBSD__ || __DragonFly__ */ static char char1[] = "pqrstuvwxyzPQRST"; static char char2[] = "0123456789abcdef"; #endif diff --git a/configure.ac b/configure.ac index 8bba78c56..e3ff0aca4 100644 --- a/configure.ac +++ b/configure.ac @@ -2400,6 +2400,37 @@ dnl --------------- zsh_CHECK_SOCKLEN_T +dnl --------------- +dnl Check for openpty support +dnl --------------- +AH_TEMPLATE([HAVE_OPENPTY], + [Define to 1 if you have the `openpty' function.]) +AH_TEMPLATE([OPENPTY_REQUIRES_PTY], + [Define to 1 if the `openpty' function requires pty.h.]) +AH_TEMPLATE([OPENPTY_REQUIRES_UTIL], + [Define to 1 if the `openpty' function requires termios.h and util.h.]) +AC_MSG_CHECKING([for openpty]) +openpty=no +AC_LINK_IFELSE([AC_LANG_SOURCE( +[[#include<pty.h> +int main () { int (*p)(int *, int *, char *, const struct termios *, const struct winsize *) = openpty; }]])], + [AC_DEFINE([HAVE_OPENPTY]) + AC_DEFINE([OPENPTY_REQUIRES_PTY]) + openpty=yes]) +if test $openpty = no; then +AC_LINK_IFELSE([AC_LANG_SOURCE( +[[#include<termios.h> +#include <util.h> +int main () { int (*p)(int *, int *, char *, const struct termios *, const struct winsize *) = openpty; }]])], + [AC_DEFINE([HAVE_OPENPTY]) + AC_DEFINE([OPENPTY_REQUIRES_UTIL]) + openpty=yes]) +fi +AC_MSG_RESULT([$openpty]) +if test $openpty = yes; then +AC_SEARCH_LIBS(openpty, util) +fi + dnl --------------- dnl Check for pty multiplexer for use in pty module. dnl We need to open it read/write, so make sure it is writeable. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Hang in E01 due to zpty on OpenBSD 2022-04-06 12:53 ` Matthew Martin @ 2022-04-06 20:12 ` Bart Schaefer 2022-04-07 3:47 ` Jun T 1 sibling, 0 replies; 15+ messages in thread From: Bart Schaefer @ 2022-04-06 20:12 UTC (permalink / raw) To: Zsh hackers list On Wed, Apr 6, 2022 at 5:55 AM Matthew Martin <phy1729@gmail.com> wrote: > > I'd prefer something like the below where it's a feature test instead of > an OS test. +1 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Hang in E01 due to zpty on OpenBSD 2022-04-06 12:53 ` Matthew Martin 2022-04-06 20:12 ` Bart Schaefer @ 2022-04-07 3:47 ` Jun T 2022-04-07 4:52 ` Matthew Martin 1 sibling, 1 reply; 15+ messages in thread From: Jun T @ 2022-04-07 3:47 UTC (permalink / raw) To: zsh-workers > 2022/04/06 21:53, Matthew Martin <phy1729@gmail.com> wrote: > > I'd prefer something like the below where it's a feature test instead of > an OS test. I was thinking that we should better minimize the possible side effects just before the new release. If we use your patch (with some fixes) openpty() will be used on ALL systems (Linux, other BSDs and macOS, ...) if it is available. Is this what you want to achieve? It may work but we need to test on lots of systems. > diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c (snip) > +#elifdef USE_DEV_PTMX #elif defined(USE_DEV_PTMX) > -#elif defined(__OpenBSD__) > - static char char1[] = "pqrstuvwxyzPQRST"; > - static char char2[] = "0123456789" > - "abcdefghijklmnopqrstuvwxyz" > - "ABCDEFGHIJKLMNOPQRSTUVWXYZ"; I think we need to keep this in case openpty() is not available on OpenBSD. > diff --git a/configure.ac b/configure.ac (snip) > +AC_MSG_CHECKING([for openpty]) > +openpty=no We need to call AC_SEARCH_LIBS(openpty, util) here to add -lutil to LIBS. Otherwise the following two AC_LINK_IFELSE() fail and openpty() will never be used. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Hang in E01 due to zpty on OpenBSD 2022-04-07 3:47 ` Jun T @ 2022-04-07 4:52 ` Matthew Martin 2022-04-08 7:51 ` Jun T 0 siblings, 1 reply; 15+ messages in thread From: Matthew Martin @ 2022-04-07 4:52 UTC (permalink / raw) To: zsh-workers On Thu, Apr 07, 2022 at 12:47:18PM +0900, Jun T wrote: > > > 2022/04/06 21:53, Matthew Martin <phy1729@gmail.com> wrote: > > > > I'd prefer something like the below where it's a feature test instead of > > an OS test. > > I was thinking that we should better minimize the possible side effects > just before the new release. > > If we use your patch (with some fixes) openpty() will be used on ALL systems > (Linux, other BSDs and macOS, ...) if it is available. Is this what you > want to achieve? It may work but we need to test on lots of systems. I was thinking I'd wait until after the release and put the patch in the OpenBSD port until the next release. That way things are fixed with no need to rush. > > diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c > (snip) > > +#elifdef USE_DEV_PTMX > #elif defined(USE_DEV_PTMX) > > > -#elif defined(__OpenBSD__) > > - static char char1[] = "pqrstuvwxyzPQRST"; > > - static char char2[] = "0123456789" > > - "abcdefghijklmnopqrstuvwxyz" > > - "ABCDEFGHIJKLMNOPQRSTUVWXYZ"; They no longer really support the /dev/ptyxx route. When I asked the response I got was, why do you think that should work it's dead and archaic. If openpty is removed in the future, falling back to /dev/pty is unlikely to be an option. > > diff --git a/configure.ac b/configure.ac > (snip) > > +AC_MSG_CHECKING([for openpty]) > > +openpty=no > > We need to call AC_SEARCH_LIBS(openpty, util) here to add -lutil to LIBS. > Otherwise the following two AC_LINK_IFELSE() fail and openpty() will never > be used. It worked here, but I don't claim to be an auto* expert. So just put the AC_SEARCH_LIBS before AC_MSG_CHECKING (otherwise the output is mixed up)? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Hang in E01 due to zpty on OpenBSD 2022-04-07 4:52 ` Matthew Martin @ 2022-04-08 7:51 ` Jun T 0 siblings, 0 replies; 15+ messages in thread From: Jun T @ 2022-04-08 7:51 UTC (permalink / raw) To: zsh-workers > 2022/04/07 13:52, Matthew Martin <phy1729@gmail.com> wrote: > > I was thinking I'd wait until after the release and put the patch in the > OpenBSD port until the next release. That way things are fixed with no > need to rush. OK, but for the next release: I tried openpty() on Fedora-35 but it didn't work (W02jobs hangs). posix_openpt() does not work on OpenBSD. I can't think of any simple way to decide which of them to use other than using OS test. # or maybe we need to make zpty more robust?, but how? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Hang in E01 due to zpty on OpenBSD 2022-04-03 21:42 Hang in E01 due to zpty on OpenBSD Matthew Martin 2022-04-04 1:04 ` Bart Schaefer @ 2022-04-04 2:39 ` Jun T 2022-04-04 2:51 ` Matthew Martin 1 sibling, 1 reply; 15+ messages in thread From: Jun T @ 2022-04-04 2:39 UTC (permalink / raw) To: zsh-workers > 2022/04/04 6:42, Matthew Martin <phy1729@gmail.com> wrote: > I'd appreciate if anyone could confirm the below is an accurate minimal > reproducer to report to OpenBSD. I tried it on OpenBSD-7.0, but it worked (no error): % doas -u _pbuild ./a.out 3: /dev/ptyp0 4: /dev/ttyp0 I also tried build/test the git master (as _pbuild), but it didn't hang. Did you try manually running zpty? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Hang in E01 due to zpty on OpenBSD 2022-04-04 2:39 ` Jun T @ 2022-04-04 2:51 ` Matthew Martin 0 siblings, 0 replies; 15+ messages in thread From: Matthew Martin @ 2022-04-04 2:51 UTC (permalink / raw) To: zsh-workers On Mon, Apr 04, 2022 at 11:39:41AM +0900, Jun T wrote: > > > 2022/04/04 6:42, Matthew Martin <phy1729@gmail.com> wrote: > > > I'd appreciate if anyone could confirm the below is an accurate minimal > > reproducer to report to OpenBSD. > > I tried it on OpenBSD-7.0, but it worked (no error): > > % doas -u _pbuild ./a.out > 3: /dev/ptyp0 > 4: /dev/ttyp0 > > I also tried build/test the git master (as _pbuild), but it didn't hang. > > Did you try manually running zpty? Yes zmodload zsh/pty zpty subshell true would run fine under my user, but not under _pbuild. I'm on -current, but I suspect the issue has been there for awhile since there's been a failing test for a few releases. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2022-04-08 7:52 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-04-03 21:42 Hang in E01 due to zpty on OpenBSD Matthew Martin 2022-04-04 1:04 ` Bart Schaefer 2022-04-04 2:34 ` Matthew Martin 2022-04-04 3:49 ` Matthew Martin 2022-04-04 8:34 ` Jun T 2022-04-04 11:21 ` Mikael Magnusson 2022-04-04 13:16 ` Matthew Martin 2022-04-06 5:48 ` Jun T 2022-04-06 12:53 ` Matthew Martin 2022-04-06 20:12 ` Bart Schaefer 2022-04-07 3:47 ` Jun T 2022-04-07 4:52 ` Matthew Martin 2022-04-08 7:51 ` Jun T 2022-04-04 2:39 ` Jun T 2022-04-04 2:51 ` Matthew Martin
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).