[screen-devel] [bug #61749] pty race between parent and child processes

[Valery Ushakov]

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/