Bug 70484 - ncurses apps hang when ^S pressed on keyboard on startup
 Summary: ncurses apps hang when ^S pressed on keyboard on startup
 Status: Product: CLOSED WORKSFORME Aliases: None Red Hat Linux Retired ncurses (Show other bugs) --- 7.2 i386 Linux medium Severity medium --- Target Release: --- Eido Inoue Jay Turner Show dependency tree / graph

 Reported: 2002-08-01 13:59 EDT by Mike Gahagan 2015-01-07 18:58 EST (History) 4 users (show) curtisz dickey srevivo tao Bug Fix --- 2004-02-19 14:54:03 EST --- --- --- --- --- --- ---

Attachments (Terms of Use)

None (edit)
 Mike Gahagan 2002-08-01 13:59:14 EDT 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' 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. Karsten Hopp 2002-08-07 09:25:58 EDT Thats not a bug. Control-S is always used to halt any output on terminals, Control-Q continues. Karsten Hopp 2002-08-07 09:32:07 EDT ok, I've misread the report. The problem isn't the ^-S but an uninterruptable loop in ncurses. Thomas E. Dickey 2003-01-11 14:40:19 EST 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. James McDermott 2003-02-06 16:43:47 EST 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? Thomas E. Dickey 2003-02-09 14:27:21 EST I thought this too obvious to mention, but terminal apps that are not running in raw mode do respond to XON/XOFF (^S/^Q). Eido Inoue 2003-02-20 16:34:45 EST I've tried and tried and tried, but I can't reproduce this... only simulate it-- but ctrl-q always resumes\it. James McDermott 2003-02-20 17:07:52 EST 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. James McDermott 2003-02-20 17:44:54 EST 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. Mike Gahagan 2003-02-21 11:40:37 EST I am still able to reproduce this as well with xemacs and occationally mc. Xemacs seems to reproduce this quite reliably.  Thomas E. Dickey 2003-02-21 19:55:19 EST 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). Eido Inoue 2004-02-19 14:54:03 EST 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.