Bug 751154 - emacs --daemon goes into an infinite loop
Summary: emacs --daemon goes into an infinite loop
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Karel Klíč
QA Contact: Fedora Extras Quality Assurance
: 752936 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2011-11-03 17:01 UTC by Jonathan Corbet
Modified: 2013-03-03 23:03 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-11-25 15:58:23 UTC
Type: ---

Attachments (Terms of Use)

Description Jonathan Corbet 2011-11-03 17:01:23 UTC
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):

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

Comment 1 Karel Klíč 2011-11-14 16:11:10 UTC
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?

Comment 2 Jonathan Corbet 2011-11-17 15:25:59 UTC
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.

Comment 3 Jonathan Corbet 2011-11-17 16:17:08 UTC
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.

Comment 4 Karel Klíč 2011-11-22 16:22:27 UTC
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.

Comment 5 Karel Klíč 2011-11-25 13:54:52 UTC
*** Bug 752936 has been marked as a duplicate of this bug. ***

Comment 6 Richard W.M. Jones 2011-11-25 13:58:38 UTC
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.

Comment 7 Karel Klíč 2011-11-25 14:18:25 UTC
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.

Comment 8 Karel Klíč 2011-11-25 14:28:31 UTC
This bug has already been reported to upstream.


Comment 9 Karel Klíč 2011-11-25 14:57:53 UTC
An update to emacs-23.3-16.fc17 should fix the issue.

Comment 10 Richard W.M. Jones 2011-11-25 15:50:56 UTC
Yes, -16 fixes the problem, thanks!

Comment 11 Aidan Delaney 2012-02-14 18:20:14 UTC
Any chance of getting an update in Fedora 16?  This would stop "emacs -nw" hanging.

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