URL:
<https://savannah.gnu.org/bugs/?61749>
Summary: pty race between parent and child processes
Project: GNU Screen
Submitted by: uwe
Submitted on: Fri 31 Dec 2021 12:37:55 AM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Release: 4.8.0
Discussion Lock: Any
Fixed Release: None
Planned Release: None
Work Required: None
_______________________________________________________
Details:
There seems to be a race between MakeWindow selecting the master side and the
ForkWindow opening the slave side.
On NetBSD (HAVE_SVR4_PTYS):
$ screen -S test -c /dev/null -ln -d -m -p 0 sh; sleep 1; screen -S test -X
quit
No screen session found.
The command sometimes succeeds in creating a session and sometimes not. When
it fails to create a session, the SCREEN.$$ debug log contains
+ hit ev fd 5 type 1!
going to read from window fd 5
Window 0: EOF (errno 0) - killing window
As far as I can tell what happens that the parent calls select on the master
fd while the child still has not opened the slave side. NetBSD select/poll
report the fd as readable and the read returns EOF.
Here's a bit of ktrace from a failed attempt:
$ kdump | sed -n -e '/select/p' -e '/EOF/p' \
-e '/\/dev\/pts/{' -e 'N' -e '/open/p' -e '}'
4831 4831 screen CALL
__select50(0x100,0x7f7fff3739f0,0x7f7fff373a10,0,0)
4831 4831 screen RET __select50 1
"Window 0: EOF (errno 0) - killing window\n"
5218 5218 screen NAMI "/dev/pts/7"
5218 5218 screen RET open 0
vs. a successful one:
19165 19165 screen CALL
__select50(0x100,0x7f7fff30a910,0x7f7fff30a930,0,0)
26839 26839 screen NAMI "/dev/pts/7"
26839 26839 screen RET open 0
19165 19165 screen RET __select50 1
"serv_select_fn called\n"
19165 19165 screen CALL
__select50(0x100,0x7f7fff30a910,0x7f7fff30a930,0,0)
19165 19165 screen RET __select50 1
Using brute-force and setting pty_preopen = 1; in OpenPTY seems to fix it as
the slave side is now always open already when the parent selects on the
master fd.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?61749>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
