emacs -nw freezes with 100% CPU with glib 2.31
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
GNU Emacs |
Unknown
|
Unknown
|
|||
Fedora |
Won't Fix
|
Undecided
|
|||
emacs23 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
After glib2.0 2.31.2 was uploaded to precise, ‘emacs -nw’ freezes at startup, going into an infinite loop at 100% CPU usage. A backtrace starts as follows:
#0 xg_select (max_fds=4, rfds=0x7fffd264
timeout=
#1 0x000000000059cd8e in wait_reading_
microsecs=
wait_
#2 0x00000000004f0309 in kbd_buffer_
used_
#3 read_char (commandflag=0, nmaps=0, maps=0x0, prev_event=
used_
…
which matches a known upstream bug: http://
Changed in fedora: | |
importance: | Unknown → Undecided |
status: | Unknown → Won't Fix |
Description of problem:
I run emacs in the server / emacsclient mode. Occasionally all emacs windows will stop responding to character input - though they will will respond to mouse clicks. Sometimes, I can recover by hitting ^G in all windows until one takes it. Other times, the only way out is to kill all emacsclient processes, at which point new emacsclient invocations can connect to the daemon and things work.
Version-Release number of selected component (if applicable): 3-4.fc16. x86_64
emacs-23.
How reproducible: Happens daily, but not on command.
Steps to Reproduce:
1. Run emacs with emacsclient
2. Suddenly notice it's ignoring you
3.
Actual results:
No response from emacs windows
Expected results:
The $#*$! thing should be listening to me.
Additional info:
I cannot reproduce the focus problem described in #674140, so I think this is a different bug.