bugGNU Screen - Bugs: bug #11610, XON (Ctrl-S) halts screen 4.0.2

 
 

bug #11610: XON (Ctrl-S) halts screen 4.0.2

Submitter:  None
Submitted:  Sun 16 Jan 2005 06:59:23 AM UTC
Votes: 42
 
Category:  Crash/Freeze/Infloop Severity:  3 - Normal
Priority:  * 8 Status:  Need Investigation
Privacy:  Public Assigned to:  None
Open/Closed:  Open Release:  None
Fixed Release:  None Planned Release:  4.1.0
Work Required:  1 - Days
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 24 Jun 2013 12:19:21 PM UTC, comment #21: 

Uhm Jürgen, I said it works for me, that means, it does not fail to unfreeze on ^Q.

Thorsten Glaser <mirabilos>
Mon 24 Jun 2013 12:15:40 PM UTC, comment #20: 

Thorsten, when it happens again and you are in step 2), "waiting", can you please run strace and lsof as root on the screen backend process?

I'd like to confirm if it blocks on a write() and if so which filedescriptor.

Juergen Weigert <jnweiger>
Group administrator
Mon 24 Jun 2013 12:02:21 PM UTC, comment #19: 

FWIW, WFM in xterm (both MirBSD and Debian), and I think XON/XOFF handling is an important feature – as I’m often using screen on a DEC VT420 on a SPARCstation.

Thorsten Glaser <mirabilos>
Thu 06 Jun 2013 02:10:18 AM UTC, comment #18: 

This happens to be all the time.

I'm in screen, I accidentally hit Ctrl-S, and it freezes.  I immediately press Ctrl-Q and nothing happens.  Keep pressing Ctrl-Q over and over--screen is frozen.  Can't detach it.

My solution has been:
(1) leave the original ssh and screen open
(2) from another ssh, submit many detach requests:
    "screen -d 10359 &"
(2) wait 5-10 min while those jobs are trying to detach it
(3) try Ctrl-Q again in the original screen
(4) MAGICALLY it wakes up and detaches
(5) reattach

I don't know why this works, but it usually does!


Anonymous
Wed 12 Oct 2011 04:21:32 PM UTC, comment #17: 

Ctrl-Q often does not work in my rxvt. Sometimes it does. When it doesn't, killing the terminal then reattaching the screen session to another is the only way to unfreeze it.

Whit Blauvelt <wytcld>
Wed 28 Apr 2010 05:25:56 PM UTC, comment #16: 

I have given constructive input in comment #7, two years ago. But I can elaborate on this once more, if needed.

IMHO, the correct solution for this is to enable the IXANY setting of the tty driver.

This would add the needed user friendlyness, by allowing any key to be pressed instead of just ignoring anything but CTRL-Q, which appears to me a very insane default of the tty-drivers.

I do not believe that this issue is directly caused by screen doing something wrong. It happens just the same in xterm: You press CTRL-S once, then you have to press CTRL-Q or --not knowing this-- kill the xterm.
Screen makes you type a lot of CTRL-xxx combinations that are dangerously near to CTRL-S on the keyboard.
That and the fact that screen can cascade mutiple layers of road-blocks ontop of each other makes it an severe usability issue.

If my guesswork in comment #10 turns out to be correct, then this is not becoming a non-issue at all, but much worse. We may have to track down a deadlock.

Anybody out there, who dares diving into the code for this? I'll assist the best I can.

Juergen Weigert <jnweiger>
Group administrator
Wed 28 Apr 2010 08:02:49 AM UTC, comment #15: 

Can we identify who is saying this isn't an issue? Yeah, I just googled and found the ctrl-q, this actually worked for me, however ctrl-s is far too easy to hit. I was in emacs, quit out, wanted to ctrl-a-d, but hit ctlr-s. It is annoying, breaks your stride.

This is a five year old issue. Can someone summarize, is it screen applying this shortcut? Why doesn't it optionally (but by default) update the display with 'stopped with ctrl-s, ctrl-q to start'?

Juergen Weigert seems to be one of the ones trying to make this a non-issue, rather than putting a constructive effort forward to address it.

Anonymous
Tue 03 Feb 2009 02:31:18 PM UTC, comment #14: 

That SIGHUP tip was fantastic.  I just shot down the screen instance.  Could have done that easier, but actually, I wanted to keep it.  Great.

Anonymous
Tue 30 Sep 2008 03:42:49 AM UTC, comment #13: 

@ Juergen Weigert:
Was bit annoyed, since I've managed to do that 4 times this year. The usability problem is that Ctrl and Shift are very close to each other, and Shift is very commonly used (unless you are a b-tard who needs only CAPS LOCK or retarded in some other way which prevents you from using capital letters and other things people usually use in written language). Basically, "mistyping" capital S (Shift-S) to Ctrl-S, causing this, is way too easy. At least for me. :d
I know some people don't do it, and by the years I've spent by the keyboard I shouldn't be doing it either. But I do... And I maybe also mixing it with Alt as well. Anyway, pressing Ctrl-S or anything with similar consequences should be bit harder to do by accident.

I think I unbound some of the things I could break everything with by pressing them... So I hope I'm safe.
(I can kill from bash if needed, so I don't think I really need anything else except attaching and detaching)

Anonymous
Sun 28 Sep 2008 11:34:12 PM UTC, comment #12: 

To me this looks like this report is not about a xon/xoff issue.
Possibly screen gets caught in a blocking write.
If so, SIGHUP could do the trick.


(Btw.
On all systems I've tested so far, CTRL-S can be undone by CTRL-Q, so usability is ususally closer to top than you may expect. I never test debian, though.

You may also want to come forth with a list of "some of the idiotic key combinations", so that we know what we are actually discussing here.)

Juergen Weigert <jnweiger>
Group administrator
Sun 28 Sep 2008 01:17:55 AM UTC, comment #11: 

Hi... Pressed Ctrl-S again, accidently... Screen froze up. I don't even remember how to undo that, and my irssi already pinged out.. Tried the combinations mentioned here, and nothing. Please. Is there a way to remove/change some of the idiotic key combinations? Killing the whole thing by pressing Ctrl instead of Shift isn't like top usability.

Anonymous
Thu 26 Jun 2008 09:18:29 AM UTC, comment #10: 

Hm, but the reproduction steps in the Original Description specifically mention C-q and C-a failing to work, so I'm not sure issue (1) applies?

Micah Cowan <micahcowan>
Wed 25 Jun 2008 06:31:49 PM UTC, comment #9: 

My guess is, that this bug is two issues.

a) User is not aware that he needs to press CTRL-Q or CTRL-A q.
   I suggest to go for IXANY to solve this.

b) Screen stumbles into a blocking write() although the  
   filedescriptor was earlier checked with select() as not 
   writable.

Juergen Weigert <jnweiger>
Group administrator
Mon 23 Jun 2008 12:58:22 PM UTC, comment #8: 

Any news???

Anonymous
  Spam posted by anonymous
  Spam posted by anonymous
Tue 22 Mar 2005 11:12:34 PM UTC, comment #5: 

I think the Debian patch is more so for dealing the CTRL-S problem where as the patch I provided  ( file #2120 ) deals with connections that are blocking but disconnected (as in those from SSH). I think both patches should be combined and tested to see if their combination does solve the problem. Regardless this bug has cost me a lot of time and I've been using the patched screen for over a month now without any new problems.

-Deleted Account- <abez>
Sun 27 Feb 2005 10:00:48 PM UTC, comment #4: 

Debian tracks this bug at:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=157873

There is an alternate patch there which was named a workaround  either one should be integrated into the next release...

Anonymous
Sat 26 Feb 2005 04:37:54 PM UTC, comment #3: 

same problem on debian sarge, I experianced this a number of times and your Recipe works perfectly to demonstrate the bug
and that the fix works.

I can also simply replace

  • Panic, since ctrl-Q doesn't work. Ctrl-A doesn't work.


with

  • Press C-a ESC as if you would like to switch to copy mode


so its even more exact then.

I think this justifies releasing a screen-4.0.3 because
this problem costs really an immense amount of productivity,
I'm not the only user which is affected by it, I was only
getting to use screen because somebody else had the same
problem but it was unclear how to reproduce it.

Bernhard Kaindl - http://ffii.org (you can google my email)

Anonymous
Fri 11 Feb 2005 06:00:41 PM UTC, comment #2: 

I believe CTRL-S actually does XOFF, rather than XON.  In any case, I too have the same problem with my version of GNU Screen.  Sometimes when I press CTRL-S, SCREEN locks up, and pressing CTRL-Q to turn flow-control on (XON) does not do anything.

Trying to log in again to detach and re-attach Screen does not do anything either.

My GNU Screen version is 4.00.02 under Debian GNU/Linux (Unstable).

J. Bobby Lopez <bobbylopez>
Thu 27 Jan 2005 09:07:50 AM UTC, comment #1: 

I had this problem too. Using Pine and Epic together and disconnecting often would cause this issue. I did some debugging (http://churchturing.org/w/screendebug) and found that the server was at fault when querying non existent displays.

with Screen version 4.00.02 (FAU) 5-Dec-03 I had this problem.

My solution which seems to work for me is to add an alarm. I use sigsetjmp and siglongjmp to skip over the blocking routines so that is a warning. Display.c had 2 routines that would block indefinately.

I am attaching both my changed display.c (http://churchturing.org/w/display.c) and the diff -up old new.

This was tested on Fedora Core 2 on a Pentium 4, and on a K6-2 with RH9.

My patches are of course released to the FSF and GPL2'd.

-Deleted Account- <abez>
Sun 16 Jan 2005 06:59:23 AM UTC, original submission:  

OK, here's a bug, or at least what is a bug on my system.

Recipie:

  • Using screen version 4.0.2-r1 (gentoo -r1)
  • ssh to remote box
  • reattach to existing screen session, with two sessions active
  • During text output stream, type ctrl-s
  • Panic, since ctrl-Q doesn't work. Ctrl-A doesn't work.
  • Kill SSH session
  • new ssh session
  • screen -D -R
  • screen never reattaches, but hangs (ctrl-C terminates process)


Apologies if this is a known bug, or fixed in a newer revision. Thanks for screen!

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #2448:  screendebug added by abez (2KiB - application/octet-stream - Debugging output and notes)
file #2447:  display.c added by abez (79KiB - text/x-csrc - My display.c)
file #2446:  display.c.diff added by abez (1KiB - text/x-patch - My patch to display.c )

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mirabilos (Posted a comment)
  • -email is unavailable- added by wytcld (Posted a comment)
  • -email is unavailable- added by mtd (Voted in favor of this item)
  • -email is unavailable- added by jnweiger (Posted a comment)
  • -email is unavailable- added by micahcowan (Updated the item)
  •  

    There are 42 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-11-25 mtd Carbon-Copy- Added mtd
    2008-07-15 micahcowan Priority5 - Normal 8
    2008-06-23 micahcowan CategoryNone Crash/Freeze/Infloop
        Planned ReleaseNone 4.1.0
        Work RequiredNone 1 - Days
    2008-06-15 micahcowan StatusNone Need Investigation
    2005-12-27 cfaerber Carbon-Copy- Added -email is unavailable-
    2005-08-17 miernik Carbon-Copy- Added -email is unavailable-
    2005-01-27 abez Attached File- Added screendebug, #2122
    2005-01-27 abez Attached File- Added display.c, #2121
    2005-01-27 abez Attached File- Added display.c.diff, #2120

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code