Bug 70484 - ncurses apps hang when ^S pressed on keyboard on startup
Summary: ncurses apps hang when ^S pressed on keyboard on startup
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ncurses (Show other bugs)
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Eido Inoue
QA Contact: Jay Turner
Depends On:
TreeView+ depends on / blocked
Reported: 2002-08-01 17:59 UTC by Mike Gahagan
Modified: 2015-01-07 23:58 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-02-19 19:54:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Mike Gahagan 2002-08-01 17:59:14 UTC
Description of Problem:

There appears to be some sort of race condition in the ncurses library which
appears to cause ncurses based apps i.e emacs to permanately hang when ^s is
pressed during startup.

Version-Release number of selected component (if applicable):

7.2 w/ emacs is what I have seen this on mostly.. its likely that other versions
are affected as well.

How Reproducible:

fairly reliably.. especially with apps that take a bit of time to start up. 

'xemacs -nw' <enter>
immeadiately hit "^s".

emacs will hang, and requires a kill -9 to kill.

Steps to Reproduce:
1. start a curses app
2. hit '^s' right after starting the app.
3. it will hang about 75% of the time.

Actual Results:

ncurses apps hang. its reproducable almost all the time w/ xemacs -nw, much more
 rare with other apps.

Expected Results:

^s should stop the terminal output, ^q should restore it.

Additional Information:
see this strace w/ emacs-nox... other straces appear to be similar.

This isn't true, I've just reproduced this on lacrosse with emacs-nox.
Here is the strace after it hangs and you type (nothing is shown on the screen
and kill -9 is only option)...
            write(1, "33[?1048h33[?1047h33[?25h33[?1h33=33[H"..., 36) = ?
ERESTARTSYS (To be restarted)
--- SIGIO (I/O possible) ---
ioctl(0, FIONREAD, [1])                 = 0
read(0, "r", 1)                        = 1
ioctl(0, FIONREAD, [0])                 = 0
sigreturn()                             = ? (mask now [])
write(1, "33[?1048h33[?1047h33[?25h33[?1h33=33[H"..., 36) = ?
ERESTARTSYS (To be restarted)

I am told this affects all curses apps, I can only relably reproduce this w/
emacs however.

Comment 1 Karsten Hopp 2002-08-07 13:25:58 UTC
Thats not a bug. Control-S is always used to halt any output on terminals, 
Control-Q continues.

Comment 2 Karsten Hopp 2002-08-07 13:32:07 UTC
ok, I've misread the report. The problem isn't the ^-S but an  
uninterruptable loop in ncurses.

Comment 3 Thomas E. Dickey 2003-01-11 19:40:19 UTC
It's unlikely that it is an ncurses bug per se, since emacs doesn't use ncurses for output - only as a source of termcap information.

Comment 4 James McDermott 2003-02-06 21:43:47 UTC
The reports coming in say pretty much any ncurses app which is launched and
provides time to press ^S will hang. So the evidence is pointing at ncurses. 
Also since this happens on numerous apps it lends itself to being based on a 
problem other than the app. Are there tests we can run which will assist you in
narrowing down this issue?

Comment 5 Thomas E. Dickey 2003-02-09 19:27:21 UTC
I thought this too obvious to mention, but terminal apps that are not running
in raw mode do respond to XON/XOFF (^S/^Q).

Comment 6 Eido Inoue 2003-02-20 21:34:45 UTC
I've tried and tried and tried, but I can't reproduce this... only simulate it--
but ctrl-q always resumes\it.

Comment 7 James McDermott 2003-02-20 22:07:52 UTC
If you are in RDU come by and Ill show it to you. The trick is to hit the 
CTRL+S before the program actually starts up, but after the executable 
has been initiated. It hangs everytime that I can get the click in.
The user with this problem nfs mounted their bin dir so it would be easier 
to reproduce.

Comment 8 James McDermott 2003-02-20 22:44:54 UTC
Well I feel like a bum. Try it with "mc" Hit ctrl+s a few times as its firing up
to make sure you get it, and it doesnt appear to want to come back for me with
ctrl+q. Once hung, ctrl+c or ctrl+z no longer will kill the program. Let me know
if this allows you to reproduce.

Comment 9 Mike Gahagan 2003-02-21 16:40:37 UTC
I am still able to reproduce this as well with xemacs and occationally mc.
Xemacs seems to reproduce this quite reliably.

Comment 10 Thomas E. Dickey 2003-02-22 00:55:19 UTC
still no.  "mc" (linked to ncurses indirectly because libgpm's package is
broken) does not use ncurses since it is linked to slang-utf8.  I see that
Xemacs can hang, but the only way I see to prove where the bug lies
is to compile Xemacs - and the stable version does not build on Redhat 8.0
(and Redhat doesn't provide the source), there's no point in wasting my
time on it.    I didn't get emacs to hang (a shame, since Redhat does provide
the source for that).

Comment 12 Eido Inoue 2004-02-19 19:54:03 UTC
I can't reproduce, and evidence points to a key mapping issue that may
or may not be due to ncurses. Anyway, a sanity check with the latest
ncurses with the apps in question lead me to believe that the ^S/^Q
seem to work, even on a loaded system. Perhaps in some corner/stress
case it can be reproduced. Closing.

Note You need to log in before you can comment on or make changes to this bug.