Description of problem: Trying to run emacs in client/server mode yields a an emacs process in a tight loop and very little editing joy Version-Release number of selected component (if applicable): emacs-23.3-10.fc17.x86_64 How reproducible: 100% Steps to Reproduce: 1. emacsclient -c 2. wait 3. wait 4. wait 5. ... Actual results: emacs --daemon running in a loop in the background; no emacs window. Expected results: a running editor so I can get my work done and not be thrown out on the streets and have to join Occupy Wall Street full time. Note that normal emacs (not in daemon mode) works fine. Additional info: Attaching to the process in gdb and getting a trace yields: #0 xg_select (max_fds=5, rfds=0x7fffa3a92d80, wfds=0x0, efds=0x0, timeout=0x7fffa3a92fd0) at /usr/src/debug/emacs-23.3/src/xgselect.c:59 #1 0x000000000059b6bb in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=<optimized out>, do_display=1, wait_for_cell=11680274, wait_proc=0x0, just_wait_proc=0) at /usr/src/debug/emacs-23.3/src/process.c:4981 #2 0x00000000004ee8d0 in kbd_buffer_get_event (end_time=0x0, used_mouse_menu=0x7fffa3a935c0, kbp=<synthetic pointer>) at /usr/src/debug/emacs-23.3/src/keyboard.c:4183 #3 read_char (commandflag=1, nmaps=2, maps=0x7fffa3a93450, prev_event=11680274, used_mouse_menu=0x7fffa3a935c0, end_time=0x0) at /usr/src/debug/emacs-23.3/src/keyboard.c:3081 #4 0x00000000004f097a in read_key_sequence (keybuf=0x7fffa3a93620, prompt=11680274, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1, bufsize=30) at /usr/src/debug/emacs-23.3/src/keyboard.c:9567 #5 0x00000000004f29c9 in command_loop_1 () at /usr/src/debug/emacs-23.3/src/keyboard.c:1645 #6 0x00000000005568f4 in internal_condition_case (bfun=0x4f27e0 <command_loop_1>, handlers=11747538, hfun=0x4e6140 <cmd_error>) at /usr/src/debug/emacs-23.3/src/eval.c:1492 #7 0x00000000004e436e in command_loop_2 () at /usr/src/debug/emacs-23.3/src/keyboard.c:1362 #8 0x00000000005567ca in internal_catch (tag=11740354, func=0x4e4350 <command_loop_2>, arg=11680274) at /usr/src/debug/emacs-23.3/src/eval.c:1228 #9 0x00000000004e63a9 in command_loop () at /usr/src/debug/emacs-23.3/src/keyboard.c:1341 #10 0x00000000004e644a in recursive_edit_1 () at /usr/src/debug/emacs-23.3/src/keyboard.c:956 #11 0x00000000004e6587 in Frecursive_edit () at /usr/src/debug/emacs-23.3/src/keyboard.c:1018 #12 0x00000000004136cf in main (argc=2, argv=<optimized out>) at /usr/src/debug/emacs-23.3/src/emacs.c:1833
The backtrace is the same as with fully functional 'emacs --daemon' process on Fedora 16, and emacs-23.3-11 server mode works well on F16 when the package is built for F16. I rebuilt the package, please try emacs-23.3-12.fc17. If it doesn't help, can you provide a trace of the emacsclient process as well?
Sorry for the delay, just tried with emacs-23.3-12.fc17.x86_64 and got the same result. I can give the emacsclient trace if you really need it, but please note that the behavior persists even if emacsclient is simply killed. Also, attaching to the looping emacs process with strace yields no output at all; it appears to be a pure user-space loop.
I've done a little bit of digging...the loop is at line 59 in xgselect.c: while (n_gfds > gfds_size) gfds_size *= 2; The problem being that gfds_size is zero. That, in turn, suggests that xgselect_initialize() is never being called when emacs is started in daemon mode. I don't know my way around the emacs code well enough to figure out right away why that might be, though. Also, just in case anybody wonders, I do get this behavior with "emacs -q", so it shouldn't be anything in my .emacs file.
Thank you. It seems that GPM support code brings an xg_select call before xgselect_initialize call. Please check if an update to emacs-23.3-14.fc17 fixes the issue.
*** Bug 752936 has been marked as a duplicate of this bug. ***
The duplicate bug noted in comment 5 is about 'emacs -nw' failing. It goes into a loop consuming CPU and not responding to any key presses. Note this behaviour if the same whether or not $DISPLAY is set. Also, -14 does *not* fix the emacs -nw issue.
So I have installed Rawhide and debugged this issue. As Jonathan discovered, xgselect_initialize() is never called. It also wasn't called in earlier builds of Emacs when running `emacs --daemon` or `emacs -nw`, but Emacs worked well. The breakage comes with glib 2.31.0 and later (Rawhide). Till that version, "n_gfds = g_main_context_query (context,...)" in emacs/src/xgselect.c always returned 0, because no part of Emacs attached a GPollFD or GSource to the main context. Since glib 2.31.0, g_main_context_new () in glib2/glib/gmain.c automatically registers a GWakeup instance to every newly created context: context->wakeup = g_wakeup_new (); g_wakeup_get_pollfd (context->wakeup, &context->wake_up_rec); g_main_context_add_poll_unlocked (context, 0, &context->wake_up_rec); so now "n_gfds = g_main_context_query (context,...)" sets n_gfds to 1, which results in the endless loop because gfds_size is 0. Preparing a patch.
This bug has already been reported to upstream. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9754
An update to emacs-23.3-16.fc17 should fix the issue.
Yes, -16 fixes the problem, thanks!
Any chance of getting an update in Fedora 16? This would stop "emacs -nw" hanging.