Cygwin/Screen/Reattach/SSH Bug: Pseudo-Fix Found!!

I have been debugging screen 3.09.15, patched for cygwin to accomodate
the socket permission workaround (described <a
href="http://groups.yahoo.com/group/gnu-screen/message/2643">here</a>).
 As many of you know, the cygwin'ed-version of screen has a continuing
bug: it hangs while attempting to reattach to previously-detached
screens.  This problem does not manifest itself too often when using a
local console window, but occurs *very* frequently when trying to
reattach from a remote ssh window.  Another behaviour that causes
abnormally-high reattach hangs is doing a 'screen -ls' or a 'screen
-r' to list all detached screens; this will cause the current shell
window to have a very hard time reattaching (whether local or ssh),
although opening a new shell will allow reattaching with the normal
probability.


First of all, I have found a way to make screen reattach with the same
consistency remotely as locally!  This is a big step forward on its
own--and although it is not a complete fix, I believe it should
suggest where the bug lies to facilitate fixing the actual problem. 
The fix is as follows.  In the file attacher.c, insert the following
code at line 250:

--------------------------------
printf("here\n");
sleep(3);
--------------------------------

Obviously the printf statement is probably not needed, and it is also
probably pretty obvious that I stumbled across this "fix" while trying
to learn the operation of the code. :)  But I believe the fact that
this works is very suggestive.  In other parts of the Attach()
function, you can find other calls to sleep().  For example at line
317, a call to sleep(1) is made, and the explanation given is "we
don't want to overrun our poor backend".  Perhaps the cygwin-screen's
backend is slower than normal, and my extra sleep allows the backend
not to be overrun.  Does anyone know what "backend" refers to?


Secondly, I have a debug dump which may prove useful.  As you are
aware, in any reattach attempt there are two processes involved: the
initial detached screen, and the screen which is trying to reattach to
it.  Here is an excerpt of the debug dump of the former process, the
initial detached screen:

---------------------------------
Knock - knock!
Ha, there was someone knocking on my socket??
Msg('accept: Connection aborted') (0);
 + hit ev fd 0 type 3!
serv_select_fn called
waiting for events:
 - fd 7 type 1 pri 0
 - fd 7 type 2 pri 0
 - fd 5 type 1 pri 0
 - fd 0 type 3 pri -10
 - cond ev fd 7 type 2 failed
readfds: 5 7
writefds:
 + hit ev fd 5 type 1!
Knock - knock!
Ha, there was someone knocking on my socket??
*** RecMsg: type 2 tty /dev/tty1
display: /dev/tty1 display not found
Checking pid 2408
secopen(/dev/tty1, 0xc002, 0000)
RecMsg: apid 2408 is o.k. and we just opened '/dev/tty1'
FindUserPtr kkant found, id 0
New event fd 4 type 1 queued 0
-------------------------------------------

Here, the first "Knock Knock" at the top corresponds to a failed
reattach attempt by another screen process.  Notice the third line:
"Msg('accept: Connection aborted') (0);".  Clearly this is the wrong
message, and either the sender is mis-sending it or the receiver is
mis-receiving it, or the message is being corrupted in between.  The
second "Knock Knock" near the middle of this excerpt corresponds to a
successful reattach from another screen process.  Notice that now the
received message is now reported as "*** RecMsg: type 2 tty /dev/tty1".


So, there are my initial observations.  I am going to keep trying to
find the problem, but in the meantime hopefully this information helps
some of you others who may have more experience with this code than
myself. :)



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/gnu-screen/

<*> To unsubscribe from this group, send an email to:
     [email protected]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/