Screen hangs when reattaching after lost ssh connection

[Benjamin Rubin]

Binary package hint: screen

I am currently running Hardy with screen 4.0.3-7ubuntu1

Screen hangs when attempting to reattach (using screen -dr) after an ssh connection is lost. It appears that this is related to or the same issue as "XON (Ctrl-S) halts screen", which has been open in Screen's bugtracker for well over 3 years: https://savannah.gnu.org/bugs/?func=detailitem&item_id=11610

[Adam Lazur (zal)]

So the normal behavior when a terminal has stopped output is that screen
will loop (high cpu usage!) trying to write to the pty and getting EIO
until the output has been started again.

In the scrollback case, we jump out of the output looping and spit out
the following debug output:

MarkRoutine called: fore nr 0, display /dev/pts/2
Entering new layer on top of 0x1007de0c: 0x1013d630
layer is blocking
...and is first, so window gets blocked
---LGotoPos 21 41
LMsg('Welcome to hacker's treasure zoo - Column 22 Line 42(+8192)
(80,42)') (0x1
013d630);
using STATLINE 41
GotoPos (21,41) -> (0,41)
Flush(): 82

And thereafter we're hung.

strace yields that the screen process is blocking in the write about the
hacker's treasure zoo.

I don't know enough about the way this stuff works code-wise, so I'll
spend some time poking around the source and try to figure out a fix.

--
Adam Lazur, Cluster Monkey

[Maximiliano Curia (maxy)]

Package: screen
Version: 4.0.2-3
Tags: patch
Followup-For: Bug #157873

*** Please type your report below this line **

Damián Viano and I, found some extra information about this bug.

This bug is activated in help, command and copy mode. And it's triggered
by calling the InitOverlayPage function.

First, the 'select()' infinite loop when pressing CTRL-S is gone in
kernel 2.6.x . (weird)

Second, the hung in the write could be workaround applying the attached
patch, it's a hack so screen doesn't call some weirds tcsetattr, in this
cases.

There is another way to avoid this, using C-a f, to set -flow, it will
not hang, in fact in this way pressing C-s will act as C-a s. (Should be
default?)

I'll keep looking this bug, when I've got some sleep.

Thanks.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i586)
Kernel: Linux 2.6.6-1-386
Locale: LANG=spanish, LC_CTYPE=spanish (ignored: LC_ALL set to es_AR)

Versions of packages screen depends on:
ii base-passwd 3.5.7 Debian base system master password
ii debconf 1.4.29 Debian configuration management sy
ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an
ii libncursesw5 5.4-4 Shared libraries for terminal hand
ii libpam0g 0.76-21 Pluggable Authentication Modules l
ii passwd 1:4.0.3-28.4 Change and administer password and

-- debconf information:
  screen/old_upgrade_prompt: false

[Bernhard Kaindl (bkaindl)]

Package: screen
Version: 4.0.2-4.1
Severity: critical
Followup-For: Bug #157873

This bug is also reported under the screen web site on savannah:

https://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=11610

In comment #1, he gave a solution which adds an alarm. He uses
sigsetjmp and siglongjmp to skip over the blocking routines
which works fine here.

This is a really highly critical problem because it causes that
all applications which were running below the hard hanging screen
have to be killed since the screen in really dead beyong recovery.

Either this or the other fix which was already given must be applied...
Bernhard

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages screen depends on:
ii base-passwd 3.5.9 Debian base system master password
ii debconf 1.4.30.11 Debian configuration management sy
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libncursesw5 5.4-4 Shared libraries for terminal hand
ii libpam0g 0.76-22 Pluggable Authentication Modules l
ii passwd 1:4.0.3-30.9 change and administer password and

-- debconf information excluded

[Justin Pryzby (justinpryzby-users)]

tag 157873 confirmed patch

[Justin Pryzby (justinpryzby-users)]

forwarded 157873 https://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=11610

[Jan Christoph Nordholz (hesso)]

Hi,

I have finally made up my mind and implemented my own workaround,
which I'll include in 4.0.3-3. It gets by without alarm signals and
jumping (which is always a bit awkward to debug) but uses an additional
call to select() instead to make sure the socket in question won't block.

The solution is still rather hackish (the unblocking ^Q is sometimes
consumed by screen itself when it happens to be in the other select()
waiting for input for the copy mode - a second ^Q is necessary in those
cases), but this is only a small inconvenience that downgrades the bug
from important to minor.

Regards,

Jan

[Benjamin Rubin (bnrubin)]

Binary package hint: screen

I am currently running Hardy with screen 4.0.3-7ubuntu1

Screen hangs when attempting to reattach (using screen -dr) after an ssh connection is lost. It appears that this is related to or the same issue as "XON (Ctrl-S) halts screen", which has been open in Screen's bugtracker for well over 3 years: https://savannah.gnu.org/bugs/?func=detailitem&item_id=11610

[Jan Christoph Nordholz (hesso)]

package screen
severity 157873 minor
retitle 157873 Ctrl-S + copy mode hangs screen (partially solved)
thankyou

[ikari (d-launchpad-ikari-pl)]

Great, I have this one too under OpenSUSE...

[Robie Basak (racb)]

Closing following Debian, as I think the same bug affects both so I'm deferring to Debian's decision. If this is wrong, please explain and reopen.

[Axel Beckert (xtaran)]

Robie: I wondered if I should do that, too, but I was unsure if it really was the same bug since there was no mentioning of Ctrl-S/XON except in the reference to the upstream bug report which might be same issue or not.

But yeah, it's probably better if someone writes a fresh reports in case this issue still can be observed.