comment #22:

>
> So, I didn't notice anything bad.
>

Thanks for testing.
I check it again: ctrl-s/ctrl-q works well for me (master branch).

Closed as fixed.

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

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.

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.

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.

@ 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)

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.

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.

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.

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)

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.