GNU bug report logs - #8855
dbus error at startup

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8855 in the body.
You can then email your comments to 8855 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: dbus error at startup
Date: Mon, 13 Jun 2011 13:49:23 -0400

This is with emacs from trunk, using the Lucid toolkit.

When doing:

ssh A_LOCAL_USER <at> localhost
emacs -Q

This error is shown:

(process:2012): GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit status can't be returned. This is a bug in the program calling g_spawn_sync(); either don't request the exit status, or don't set the SIGCHLD action.
GConf Error: Failed to contact configuration server; the most common cause is a missing or misconfigured D-Bus session bus daemon. See http://projects.gnome.org/gconf/ for information. (Details -  1: Failed to get connection to session: Abnormal program termination spawning command line `dbus-launch --autolaunch=5ff056e06a6f310f5110670047532bd4 --binary-syntax --close-stderr': )


then emacs starts just fine, and I can see the "dbus-launch" process with that command line is running too.
Is emacs not waiting long enough for that dbus process to start, or is there
something else going on here?

Message #8 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Dan Nicolaescu <dann <at> gnu.org>
Cc: 8855 <at> debbugs.gnu.org
Subject: Re: bug#8855: dbus error at startup
Date: Sun, 26 Jun 2011 12:22:53 +0200

Dan Nicolaescu <dann <at> gnu.org> writes:

> Is emacs not waiting long enough for that dbus process to start, or is there
> something else going on here?

It does not seem to be an error in Emacs, but in GIO. See discussion in
<https://bugzilla.redhat.com/show_bug.cgi?id=654027>.

I have no idea which SIGCHLD setting we shall apply, 'though.

Best regards, Michael.

Message #17 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 8855 <at> debbugs.gnu.org
Subject: Re: dbus error at startup
Date: Wed, 24 Oct 2012 22:35:15 -0700

[Message part 1 (text/plain, inline)]

I ran into this bug today, and have verified that it's not
a GIO bug per se, but is a bug in the interaction between
Emacs and glib, which causes Emacs to mess up glib.
Patch attached.

[g_spawn_sync.txt (text/plain, attachment)]

Message #22 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 8855 <at> debbugs.gnu.org
Subject: Re: bug#8855: dbus error at startup
Date: Thu, 25 Oct 2012 18:24:52 +0200

> Date: Wed, 24 Oct 2012 22:35:15 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> I ran into this bug today, and have verified that it's not
> a GIO bug per se, but is a bug in the interaction between
> Emacs and glib, which causes Emacs to mess up glib.
> Patch attached.

Thanks, but is there perhaps a way to fix this less intrusively,
without messing with the whole chain of functions involved in SIGCHLD
and subprocess termination?

Message #25 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8855 <at> debbugs.gnu.org
Subject: Re: bug#8855: dbus error at startup
Date: Thu, 25 Oct 2012 13:57:40 -0700

On 10/25/2012 09:24 AM, Eli Zaretskii wrote:
> is there perhaps a way to fix this less intrusively,
> without messing with the whole chain of functions involved in SIGCHLD
> and subprocess termination?

I looked for one but couldn't find one.

We could try to get the glib API fixed, but I can't offhand
think of an easy fix, and in the meantime we need to deal
with the glibs in the field with the current API, and for
those glibs we need a workaround anyway.

We could try to use process groups, so that Emacs invokes
waitpid just on a process group rather than on all children.
However, an executable can create a new process group and
join it so this would require that we create two processes
instead of one (the child simply forks and waits for the
grandchild which does the real work, so that any mucking
around by the grandchild cannot affect the child's process
group).  This would work, but it costs us one extra process
per subprocess, and I expect that in practice that'd be
worse than the proposed patch, both performance-wise and
intrusive-change-wise.

glib itself, when faced with this problem, does not use
process groups, but simply scans for all subprocesses that
it knows about, just as the proposed patch does.  See the
function dispatch_unix_signals in glib/gmain.c.

Looking at that function's callers, it may be that we can
use g_child_watch_source_new instead of waitpid, but it's
not clear to me how that would work, and I wonder whether the
result would be any less intrusive than the proposed patch.

Message #28 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8855 <at> debbugs.gnu.org
Subject: Re: bug#8855: dbus error at startup
Date: Sun, 28 Oct 2012 18:38:18 -0700

[Message part 1 (text/plain, inline)]

Attached is a slightly less-intrusive version of the patch.
It omits the removal of "#ifdef SIGCHLD", which isn't
strictly needed to fix the bug.  I don't see any further
simplifications, unfortunately.  The patch fixes a bug that's
been reported multiple times so I'm thinking it may be
worthwhile to install now, even though there's a feature
freeze.

[g_spawn_sync.txt (text/plain, attachment)]

Message #31 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 8855 <at> debbugs.gnu.org
Subject: confirmation from glib side
Date: Sun, 28 Oct 2012 23:27:50 -0700

I got confirmation from Colin Walters that the Emacs code
is currently broken, with respect to glib, and that the
approach taken by the proposed patch is the right one.
See <https://bugzilla.gnome.org/show_bug.cgi?id=687075#c2>.

Message #34 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 8855 <at> debbugs.gnu.org
Subject: Re: bug#8855: dbus error at startup
Date: Mon, 29 Oct 2012 17:24:28 +0800

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> Attached is a slightly less-intrusive version of the patch.
> It omits the removal of "#ifdef SIGCHLD", which isn't
> strictly needed to fix the bug.  I don't see any further
> simplifications, unfortunately.  The patch fixes a bug that's
> been reported multiple times so I'm thinking it may be
> worthwhile to install now, even though there's a feature
> freeze.

I think the patch is OK to commit.  Put the extended explanation in a
comment somewhere in the code, though---not in the ChangeLog entry.

Message #37 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 8855 <at> debbugs.gnu.org
Subject: Re: bug#8855: dbus error at startup
Date: Mon, 29 Oct 2012 19:06:56 +0200

> From: Chong Yidong <cyd <at> gnu.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  8855 <at> debbugs.gnu.org
> Date: Mon, 29 Oct 2012 17:24:28 +0800
> 
> Paul Eggert <eggert <at> cs.ucla.edu> writes:
> 
> > Attached is a slightly less-intrusive version of the patch.
> > It omits the removal of "#ifdef SIGCHLD", which isn't
> > strictly needed to fix the bug.  I don't see any further
> > simplifications, unfortunately.  The patch fixes a bug that's
> > been reported multiple times so I'm thinking it may be
> > worthwhile to install now, even though there's a feature
> > freeze.
> 
> I think the patch is OK to commit.

I agree.

I also think that after the feature freeze is lifted, it would be good
to refactor the related code so that, e.g., the loop in
process_status_retrieved is joined with the loop(s) in
record_child_status_change.  Since we are now asking about a single
process at a time, I don't see why we need a loop inside a loop.
Previous code didn't have this nested-loop structure, AFAICS.

Btw, what about Posix platforms that don't have WNOHANG defined, and
therefore have 'waitpid' redirected to 'wait' -- are they the same
ones which have CAN_HANDLE_MULTIPLE_CHILDREN set to zero?  (The cpp
directives don't match.)  If some of them don't, then will this new
code work for them with 'wait'?

P.S.  Incidentally, the MS-Windows build always had a 'waitpid'-like
implementation of its 'wait' emulation, it just pretended to be
checking all of its child processes, because that's what the mainline
code wanted, but actually always knew which process it should check
for.  I guess time is ripe for refactoring that code into an emulation
of 'waitpid'.

P.P.S.  We use record_child_status_change in another place as well: in
sysdep.c:wait_for_termination_1.  Will the change in the former still
work correctly in the latter (and its callers)?

Message #40 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Chong Yidong <cyd <at> gnu.org>, 8855 <at> debbugs.gnu.org
Subject: Re: bug#8855: dbus error at startup
Date: Wed, 31 Oct 2012 00:36:18 -0700

[Message part 1 (text/plain, inline)]

On 10/29/2012 10:06 AM, Eli Zaretskii wrote:

> Since we are now asking about a single
> process at a time, I don't see why we need a loop inside a loop.

Good point, and this is a performance regression, since the
old code was O(N) and the new O(N**2).  I have fixed that
in a revised proposal (attached).  While fixing this I
found another regression, as already successfully-
waited-for processes were being waited-for again.  This is also
fixed in the revised proposal.

> Btw, what about Posix platforms that don't have WNOHANG defined,

There aren't any anymore.  Posix has required WNOHANG since
Posix.1-1988 and everybody has it implemented by now.
I've added a comment to that effect.  (I also added a comment
along the line that cyd suggested.)

> (The cpp directives don't match.)

Thanks, fixed in the attached proposal.

> I guess time is ripe for refactoring that code into an emulation
> of 'waitpid'.

Yes, that'd be nice.  The attached proposal puts that into a FIXME
comment.

> We use record_child_status_change in another place as well: in
> sysdep.c:wait_for_termination_1.  Will the change in the former still
> work correctly in the latter (and its callers)?

Yes, it should.  One uses -1 as the pid as a special indicator; the
other doesn't, and the implementation treats -1 specially.

Thanks for the review.

[g_spawn_sync.txt (text/plain, attachment)]

Message #45 received at 8855-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 8855-done <at> debbugs.gnu.org
Subject: installed patch into trunk
Date: Sat, 03 Nov 2012 11:34:25 -0700

I installed the patch into the trunk as bzr 110784
and am marking this as done.

Message #53 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 8855 <at> debbugs.gnu.org
Subject: Fix backported to Emacs 24
Date: Wed, 21 Nov 2012 15:50:59 -0800

[Message part 1 (text/plain, inline)]

Attached is the fixed backported to the emacs-24 branch
(bzr 110936) if there's interest.

[g_spawn_sync.txt (text/plain, attachment)]

Message #56 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 8855 <at> debbugs.gnu.org
Subject: Re: bug#8855: Fix backported to Emacs 24
Date: Thu, 22 Nov 2012 05:49:40 +0200

> Date: Wed, 21 Nov 2012 15:50:59 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> Attached is the fixed backported to the emacs-24 branch
> (bzr 110936) if there's interest.

The related changes for MS-Windows (r110922) are needed as well.

Message #59 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 8855 <at> debbugs.gnu.org
Subject: Re: bug#8855: Fix backported to Emacs 24
Date: Thu, 22 Nov 2012 10:13:20 -0500

> Attached is the fixed backported to the emacs-24 branch
> (bzr 110936) if there's interest.

There's something I don't understand.
On Oct 29, Chong said:

> > simplifications, unfortunately.  The patch fixes a bug that's been
> > reported multiple times so I'm thinking it may be worthwhile to
> > install now, even though there's a feature freeze.
> I think the patch is OK to commit.  Put the extended explanation in a
> comment somewhere in the code, though---not in the ChangeLog entry.

So how come the patch is not in emacs-24 yet?


        Stefan

Message #62 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 8855 <at> debbugs.gnu.org
Subject: Re: bug#8855: Fix backported to Emacs 24
Date: Thu, 22 Nov 2012 11:20:41 -0800

On 11/22/2012 07:13 AM, Stefan Monnier wrote:
> So how come the patch is not in emacs-24 yet?

I understood Chong's comment to be about the trunk, not
about emacs-24.  The trunk was frozen at the time, if
I recall, so his permission would have been needed for
the trunk.

Message #65 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 8855 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#8855: Fix backported to Emacs 24
Date: Fri, 23 Nov 2012 10:40:23 +0800

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> On 11/22/2012 07:13 AM, Stefan Monnier wrote:
>> So how come the patch is not in emacs-24 yet?
>
> I understood Chong's comment to be about the trunk, not about
> emacs-24.  The trunk was frozen at the time, if I recall, so his
> permission would have been needed for the trunk.

The emacs-24 branch hadn't even been created when I wrote that, so
"commits to the trunk" at the time meant "code going into 24.3".

Feel free to backport it now.

Message #68 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Chong Yidong <cyd <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 8855 <at> debbugs.gnu.org
Subject: Re: bug#8855: Fix backported to Emacs 24
Date: Fri, 23 Nov 2012 16:46:49 -0500

On 11/22/2012 9:40 PM, Chong Yidong wrote:
> Paul Eggert <eggert <at> cs.ucla.edu> writes:
>
>> On 11/22/2012 07:13 AM, Stefan Monnier wrote:
>>> So how come the patch is not in emacs-24 yet?
>>
>> I understood Chong's comment to be about the trunk, not about
>> emacs-24.  The trunk was frozen at the time, if I recall, so his
>> permission would have been needed for the trunk.
>
> The emacs-24 branch hadn't even been created when I wrote that, so
> "commits to the trunk" at the time meant "code going into 24.3".
>
> Feel free to backport it now.

It would be good to get this done before tomorrow's release of 24.2.90. 
 Paul, is there still time to do it?

Ken

Message #71 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: Chong Yidong <cyd <at> gnu.org>, 8855 <at> debbugs.gnu.org
Subject: Re: bug#8855: Fix backported to Emacs 24
Date: Fri, 23 Nov 2012 14:22:14 -0800

On 11/23/2012 01:46 PM, Ken Brown wrote:
> Paul, is there still time to do it?

Yes, done with Eli's suggestions as emacs-24 bzr 110946.

On 11/22/2012 06:40 PM, Chong Yidong wrote:
>
> The emacs-24 branch hadn't even been created when I wrote that, so
> "commits to the trunk" at the time meant "code going into 24.3".

Sorry about the confusion -- my memory must have been faulty.

Message #74 received at 8855 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 8855 <at> debbugs.gnu.org
Subject: Re: bug#8855: Fix backported to Emacs 24
Date: Mon, 26 Nov 2012 18:32:01 -0800

As discussed on emacs-devel, I had to undo that backport to
the emacs-24 branch.

The problem was that the fix for Bug#8855 introduces a new
bug, Bug#12980.  I have followed up at Bug#12980 but the patch
is nontrivial, so for now Bug#8855 remains unfixed on the
emacs-24 branch.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.