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.
Thats not a bug. Control-S is always used to halt any output on terminals, Control-Q continues.
ok, I've misread the report. The problem isn't the ^-S but an uninterruptable loop in ncurses.
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.
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?
I thought this too obvious to mention, but terminal apps that are not running in raw mode do respond to XON/XOFF (^S/^Q).
I've tried and tried and tried, but I can't reproduce this... only simulate it-- but ctrl-q always resumes\it.
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.
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.
I am still able to reproduce this as well with xemacs and occationally mc. Xemacs seems to reproduce this quite reliably.
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).
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.