bug#11415: 24.1.50; Dbus hangs indefinitely during batch mode & daemon startup

bug#11415: 24.1.50; Dbus hangs indefinitely during batch mode & daemon startup

[Ryan C. Thompson]

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgement at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

It seems that during the startup of any emacs without a terminal
(i.e. "--batch" or "--daemon"), recent emacs snapshots cannot make dbus
calls. Worse, any attempt to make a dbus call will hang
indefinitely. This stops me from being able to use some of my config in
emacs, since it is dbus based and cannot be loaded on startup in daemon
mode.

Specifically, I can easily reproduce the bug like this:

emacs-snapshot -Q --batch -l dbus --eval '(message
  "DBus system names: %s"
  (dbus-call-method :system dbus-service-dbus
   dbus-path-dbus dbus-interface-dbus "ListNames"))'

Running the same command with emacs 23 works just fine:

emacs23 -Q --batch -l dbus --eval '(message
  "DBus system names: %s"
  (dbus-call-method :system dbus-service-dbus
   dbus-path-dbus dbus-interface-dbus "ListNames"))'

Running the same command *without* batch mode works just fine (I add the
extra kill-emacs eval so that you can run it from the command line
without having to close emacs afterward):

emacs-snapshot -Q -l dbus --eval '(message
  "DBus system names: %s"
  (dbus-call-method :system dbus-service-dbus
   dbus-path-dbus dbus-interface-dbus "ListNames"))' \
  --eval '(kill-emacs)'

Running the same command in daemon mode triggers the bug:

emacs-snapshot -Q --daemon -l dbus --eval '(message
  "DBus system names: %s"
  (dbus-call-method :system dbus-service-dbus
   dbus-path-dbus dbus-interface-dbus "ListNames"))'

However, starting the daemon and running the dbus call through
emacsclient works fine:

emacs-snapshot -Q --daemon -l dbus;
emacsclient --eval   '(message "DBus system names: %s"
   (dbus-call-method :system dbus-service-dbus
   dbus-path-dbus dbus-interface-dbus "ListNames"))';
# Clean up
emacsclient --eval '(kill-emacs)'

I am using the Emacs 23 from the Ubuntu 12.04 repos, and the
emacs-snapshot from this PPA:
https://launchpad.net/~cassou/+archive/emacs, which I believe is
generally built weekly. This started happening within the last month or
so (I'm not sure how far behind that PPA lags, so add some time on for
that as well).

There is no backtrace or anything, because the dbus call never
returns. It just hangs until I press Control+C. I am willing to try
fixes and debug things if people will tell me what to do.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
     `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/usr/share/emacs/24.1.50/etc/DEBUG.


In GNU Emacs 24.1.50.1 (x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
  of 2012-05-02 on meitnerium, modified by Debian
  (emacs-snapshot package, version 2:20120502-1~ppa1~precise1)
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
Configured using:
  `configure '--build' 'x86_64-linux-gnu' '--host' 'x86_64-linux-gnu'
  '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
  '--localstatedir=/var' '--infodir=/usr/share/info'
  '--mandir=/usr/share/man' '--with-pop=yes'
  '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/24.1.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.1.50/site-lisp:/usr/share/emacs/site-lisp'
  '--without-compress-info' '--with-crt-dir=/usr/lib/x86_64-linux-gnu/'
  '--with-x=yes' '--with-x-toolkit=lucid' 'build_alias=x86_64-linux-gnu'
  'host_alias=x86_64-linux-gnu' 'CFLAGS=-DDEBIAN
  -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g -Wl,--as-needed
  -znocombreloc' 'CPPFLAGS=-D_FORTIFY_SOURCE=2''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: nil
   locale-coding-system: utf-8-unix
   default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:


Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
/usr/share/emacs/24.1.50/site-lisp/debian-startup hides 
/usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs/24.1.50/site-lisp/flim/hex-util hides 
/usr/share/emacs/24.1.50/lisp/hex-util
/usr/share/emacs/24.1.50/site-lisp/flim/md4 hides 
/usr/share/emacs/24.1.50/lisp/md4
/usr/share/emacs/site-lisp/rst hides 
/usr/share/emacs/24.1.50/lisp/textmodes/rst
/usr/share/emacs/24.1.50/site-lisp/flim/ntlm hides 
/usr/share/emacs/24.1.50/lisp/net/ntlm
/usr/share/emacs/24.1.50/site-lisp/flim/sasl-ntlm hides 
/usr/share/emacs/24.1.50/lisp/net/sasl-ntlm
/usr/share/emacs/24.1.50/site-lisp/flim/sasl hides 
/usr/share/emacs/24.1.50/lisp/net/sasl
/usr/share/emacs/24.1.50/site-lisp/flim/sasl-digest hides 
/usr/share/emacs/24.1.50/lisp/net/sasl-digest
/usr/share/emacs/24.1.50/site-lisp/flim/sasl-cram hides 
/usr/share/emacs/24.1.50/lisp/net/sasl-cram
/usr/share/emacs/24.1.50/site-lisp/flim/hmac-def hides 
/usr/share/emacs/24.1.50/lisp/net/hmac-def
/usr/share/emacs/24.1.50/site-lisp/flim/hmac-md5 hides 
/usr/share/emacs/24.1.50/lisp/net/hmac-md5

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting x-toolkit x
multi-tty emacs)

bug#11415: 24.1.50; Dbus hangs indefinitely during batch mode & daemon startup

[Michael Albinus]

"Ryan C. Thompson" <rct@thompsonclan.org> writes:

> It seems that during the startup of any emacs without a terminal
> (i.e. "--batch" or "--daemon"), recent emacs snapshots cannot make dbus
> calls. Worse, any attempt to make a dbus call will hang
> indefinitely. This stops me from being able to use some of my config in
> emacs, since it is dbus based and cannot be loaded on startup in daemon
> mode.
>
> Specifically, I can easily reproduce the bug like this:
>
> emacs-snapshot -Q --batch -l dbus --eval '(message
>  "DBus system names: %s"
>  (dbus-call-method :system dbus-service-dbus
>   dbus-path-dbus dbus-interface-dbus "ListNames"))'

In Emacs 24.1.50, `dbus-call-method' changed from a synchronous call to
an asynchronous one (see etc/NEWS). If Emacs runs in batch mode, it
doesn't seem to read incoming events. Therefore, the return event of the
call is not read.

I will see what can be done. Either we must enable Emacs to receive some
special input events also in batch mode. Or we must check inside
`dbus-call-method', whether Emacs runs daemonized, and use the blocking
call then.

I would prefer the first alternative, because receiving D-Bus signals and
running Emacs as D-Bus enabled server does not work either when Emacs
does not accept incoming events.

> There is no backtrace or anything, because the dbus call never
> returns.

In theory, it shall accept at least timeouts, like 

emacs -Q --daemon -l dbus --eval \
  '(message "DBus system names: %s" \
     (dbus-call-method \
      :system dbus-service-dbus dbus-path-dbus dbus-interface-dbus \
      "ListNames" :timeout 5000))'

But it doesn't, which is another bug to be fixed.

Best regards, Michael.

bug#11415: 24.1.50; Dbus hangs indefinitely during batch mode & daemon startup

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

> In Emacs 24.1.50, `dbus-call-method' changed from a synchronous call to
> an asynchronous one (see etc/NEWS). If Emacs runs in batch mode, it
> doesn't seem to read incoming events. Therefore, the return event of the
> call is not read.
>
> I will see what can be done. Either we must enable Emacs to receive some
> special input events also in batch mode. Or we must check inside
> `dbus-call-method', whether Emacs runs daemonized, and use the blocking
> call then.
>
> I would prefer the first alternative, because receiving D-Bus signals and
> running Emacs as D-Bus enabled server does not work either when Emacs
> does not accept incoming events.

I have debugged further. The problem is in kbd_buffer_get_event of
keyboard.c - it does not read special events when noninteractive. The
following patch cures the problem for me:

--8<---------------cut here---------------start------------->8---
*** /home/albinus/src/emacs/src/keyboard.c.~108144~
--- /home/albinus/src/emacs/src/keyboard.c
***************
*** 3801,3806 ****
--- 3801,3807 ----
      }
  #endif	/* subprocesses */

+ #if 0  /* We want to read special events in batch mode.  */
    if (noninteractive
        /* In case we are running as a daemon, only do this before
  	 detaching from the terminal.  */
***************
*** 3811,3816 ****
--- 3812,3818 ----
        *kbp = current_kboard;
        return obj;
      }
+ #endif

    /* Wait until there is input available.  */
    for (;;)
--8<---------------cut here---------------end--------------->8---

However, I don't know whether it has undesired side effects. What do
people think?

Best regards, Michael.

bug#11415: 24.1.50; Dbus hangs indefinitely during batch mode & daemon startup

[Christopher Schmidt]

Michael Albinus <michael.albinus@gmx.de> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
> I have debugged further. The problem is in kbd_buffer_get_event of
> keyboard.c - it does not read special events when noninteractive. The
> following patch cures the problem for me:
[...]
> However, I don't know whether it has undesired side effects. What do
> people think?

The patches fixes the problem for me as well.

To me the patch looks correct.  (I run emacs --daemon directly in my
.Xsession and do not expect any interactions until I spawn the first
frame.)

        Christopher

bug#11415: 24.1.50; Dbus hangs indefinitely during batch mode & daemon startup

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

> I have debugged further. The problem is in kbd_buffer_get_event of
> keyboard.c - it does not read special events when noninteractive. The
> following patch cures the problem for me:
>
> --8<---------------cut here---------------start------------->8---
> *** /home/albinus/src/emacs/src/keyboard.c.~108144~
> --- /home/albinus/src/emacs/src/keyboard.c
> ***************
> *** 3801,3806 ****
> --- 3801,3807 ----
>       }
>   #endif	/* subprocesses */
>
> + #if 0  /* We want to read special events in batch mode.  */
>     if (noninteractive
>         /* In case we are running as a daemon, only do this before
>   	 detaching from the terminal.  */
> ***************
> *** 3811,3816 ****
> --- 3812,3818 ----
>         *kbp = current_kboard;
>         return obj;
>       }
> + #endif
>
>     /* Wait until there is input available.  */
>     for (;;)
> --8<---------------cut here---------------end--------------->8---
>
> However, I don't know whether it has undesired side effects. What do
> people think?

Nobody has objected, so I have committed the patch. Bug closed.

Best regards, Michael.

bug#11415: 24.1.50; Dbus hangs indefinitely during batch mode & daemon startup

[Paul Eggert]

That patch had a minor issue with it, discovered by configuring with
"./configure --enable-gcc-warnings", in that it sometimes resulted
in a local variable that was never used.  I installed the following
further patch to work around this.  These days there's no point to
making such variables 'register' so I removed the 'register' while
I was at it.

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2012-05-14 15:11:10 +0000
+++ src/ChangeLog	2012-05-14 15:22:29 +0000
@@ -1,5 +1,7 @@
 2012-05-14  Paul Eggert  <eggert@cs.ucla.edu>
 
+	* keyboard.c (kbd_buffer_get_event) [!HAVE_DBUS]: Omit unused local.
+
 	* unexaix.c: Port to more-recent AIX compilers.
 	(report_error, report_error_1, make_hdr, copy_sym)
 	(mark_x, adjust_lnnoptrs, unrelocate_symbols):

=== modified file 'src/keyboard.c'
--- src/keyboard.c	2012-05-14 07:05:03 +0000
+++ src/keyboard.c	2012-05-14 15:22:29 +0000
@@ -3786,7 +3786,6 @@
                       int *used_mouse_menu,
                       struct timeval *end_time)
 {
-  register int c;
   Lisp_Object obj;
 
 #ifdef subprocesses
@@ -3809,7 +3808,7 @@
 	 detaching from the terminal.  */
       || (IS_DAEMON && daemon_pipe[1] >= 0))
     {
-      c = getchar ();
+      int c = getchar ();
       XSETINT (obj, c);
       *kbp = current_kboard;
       return obj;