Bug 751154
Summary: | emacs --daemon goes into an infinite loop | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jonathan Corbet <corbet> |
Component: | emacs | Assignee: | Karel Klíč <kklic> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | a.j.delaney, jonathan.underwood, kklic, michal, rjones, rvokal |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-11-25 15:58:23 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jonathan Corbet
2011-11-03 17:01:23 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? 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. |