screen: fhandler_socket::close() fails w/ Cygwin >= 1.5.15

[Schulman dot Andrew at epamail dot epa dot gov]

I have a working build of screen for Cygwin; see 
http://cygwin.com/ml/cygwin-apps/2005-04/msg00182.html.  This version 
runs, but it won't reattach detached sessions (on either of my XP hosts) 
using Cygwin 1.5.15 or greater.  It will reattach sessions using Cygwin 
1.5.14 or earlier.  Here are the details:

When screen runs it forks off a child process that controls further 
children (e.g. shells) that run within the screen windows.  The parent is 
attached to the tty.  When the user detaches the session, the parent 
terminates but the child and its children stay running.

The parent and child screen processes communicate by a socket (since I 
disabled FIFOs in the build configuration).  With a session attached, I 
see:

$ ls -l /tmp/uscreens/S-aschulma
total 1
srwx------  1 ASchulma None 53 May 17 12:46 4024.tty1.D77E1BASCHULMA1=

Here 4024 is the PID of the child process.  So far, so good.  Now, I issue 
the 'detach' command within the screen session.  Under Cygwin 1.5.14, I 
still see 

$ ls -l /tmp/uscreens/S-aschulma
total 1
srwx------  1 ASchulma None 53 May 17 12:46 4024.tty1.D77E1BASCHULMA1=

and I can reattach my session with no trouble.  But under Cygwin 1.5.15, 
after I detach I see

$ ls -l /tmp/uscreens/S-aschulma/
total 1
-rw-------  1 ASchulma None 53 May 17 12:51 4024.tty1.D77E1BASCHULMA1

_The socket is no longer a socket._  It has turned into a plain file.  And 
of course, I can't reattach my screen session, even though the child 
screen process is still running; screen says 'There is no screen to be 
resumed.'

I attached strace to the running parent and child processes, just before 
issuing the 'detach' command.  I did this separately using Cygwin 1.5.14 
and 1.5.15.  The logs are here:

http://home.comcast.net/~andrex/cygwin/screen/strace/screen-cygwin-1.5.14-parent.txt
http://home.comcast.net/~andrex/cygwin/screen/strace/screen-cygwin-1.5.15-parent.txt

http://home.comcast.net/~andrex/cygwin/screen/strace/screen-cygwin-1.5.14-child.txt
http://home.comcast.net/~andrex/cygwin/screen/strace/screen-cygwin-1.5.15-child.txt

(Note that I massaged these logs in order to reduce noise and make them 
easier to compare.  I removed the first two columns of timing data, and 
changed the PIDs and Thread handles in the 1.5.14 versions to match the 
ones in the 1.5.15 versions.)

Comparing the parent logs (I find CSdiff to be good for this), I don't see 
much difference.  With 1.5.14 there are a few extra calls to 
GetFileInformationByHandle and symlink.check_sysfile; that's about it.

In the child logs, these difference looks like the crucial ones (1.5.14 is 
on top, 1.5.15 below):

237,238c236,238
< [main] SCREEN 4024 fhandler_disk_file::utimes: incoming lastaccess 
428A1600 0002811D
< [main] SCREEN 4024 fhandler_base::close: closing 
'/tmp/uscreens/S-aschulma/4024.tty0.D77E1BASCHULMA1' handle 0x14C
---
> [main] SCREEN 4024 fhandler_base::utimes_fs: incoming lastaccess 
428A1544 0001D443
> [main] SCREEN 4024 __set_winsock_errno: close:1429 - winsock error 10038 
-> errno 108
> [main] SCREEN 4024 fhandler_socket::close: -1 = fhandler_socket::close()
279,282c279
< [select_socket] SCREEN 4024 thread_socket: Win32 select returned 1
< [select_socket] SCREEN 4024 thread_socket: s 0x10016978, testing fd 4 ()
< [select_socket] SCREEN 4024 thread_socket: read_ready

So as far as I can see at this point, the cause of the reattachment 
trouble appears to be a failure of fhandler_socket::close() in Cygwin >= 
1.5.15.  Is this Cygwin's fault, or screen's?  Or is it impossible to 
tell?

If anyone is interested, my current screen package is available for 
testing:

http://home.comcast.net/~andrex/cygwin/screen/setup.hint
http://home.comcast.net/~andrex/cygwin/screen/screen-4.0.2-0test1.tar.bz2
http://home.comcast.net/~andrex/cygwin/screen/screen-4.0.2-0test1-src.tar.bz2

Andrew.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/