Bug#737380: glib2.0: FTBFS on mipsel: gapplication test failed: ECHILD was received by waitpid()

2014-02-02 Thread Simon McVittie
Source: glib2.0
Version: 2.38.2-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

https://buildd.debian.org/status/fetch.php?pkg=glib2.0arch=mipselver=2.38.2-1stamp=1387885448:

# random seed: R02S852f3ece8c5f76fcefb61e81eb83e7a7
# Start of gapplication tests
ok 1 /gapplication/no-dbus
ok 2 /gapplication/basic
# GLib-FATAL-WARNING: In call to g_spawn_sync(), exit status of a child process 
was requested but ECHILD was received by waitpid(). Most likely the process is 
ignoring SIGCHLD, or some other thread is invoking waitpid() with a nonpositive 
first argument; either behavior can break applications that use g_spawn_sync 
either directly or indirectly.

(/«PKGBUILDDIR»/debian/build/deb/gio/tests/.libs/lt-gapplication:10577): 
GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was 
requested but ECHILD was received by waitpid(). Most likely the process is 
ignoring SIGCHLD, or some other thread is invoking waitpid() with a nonpositive 
first argument; either behavior can break applications that use g_spawn_sync 
either directly or indirectly.
Trace/breakpoint trap


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#737380: glib2.0: FTBFS on mipsel: gapplication test failed: ECHILD was received by waitpid()

2014-02-02 Thread Simon McVittie
Doing a test build on eder to see whether this is reproducible. mips*
porters are more than welcome to take over - I know virtually nothing
about the mips* architectures.

S


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#737380: glib2.0: FTBFS on mipsel: gapplication test failed: ECHILD was received by waitpid()

2014-02-02 Thread Simon McVittie
tags 737380 + confirmed
thanks

On 02/02/14 10:20, Simon McVittie wrote:
 # random seed: R02S852f3ece8c5f76fcefb61e81eb83e7a7
 # Start of gapplication tests
 ok 1 /gapplication/no-dbus
 ok 2 /gapplication/basic
 # GLib-FATAL-WARNING: In call to g_spawn_sync(), exit status of a
 child process was requested but ECHILD was received by waitpid().
 Most likely the process is ignoring SIGCHLD, or some other thread is
 invoking waitpid() with a nonpositive first argument; either behavior
 can break applications that use g_spawn_sync either directly or
 indirectly.
 (/«PKGBUILDDIR»/debian/build/deb/gio/tests/.libs/lt-gapplication:10577):
 GLib-WARNING **: In call to g_spawn_sync(), exit status of a child
 process was requested but ECHILD was received by waitpid(). Most
 likely the process is ignoring SIGCHLD, or some other thread is
 invoking waitpid() with a nonpositive first argument; either behavior
 can break applications that use g_spawn_sync either directly or
 indirectly.

Reproducible on eder (mipsel), mostly in test 3 (/gapplication/no-appid)
but sometimes in test 2 (/gapplication/basic).

In the source tree after the FTBFS, you can run:

debian/build/deb/gio/tests/gapplication

to see this happen.

It takes a few hours for the build to complete. I currently have a built
tree in eder:/home/smcv/tmp/glib2.0-2.38.2-2 which people might be able
to just 'cp -a'.

Regards,
S


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#737380: glib2.0: FTBFS on mipsel: gapplication test failed: ECHILD was received by waitpid()

2014-02-02 Thread Simon McVittie
This appears to be something to do with the gapplication test accidentally
trying to use `dbus-launch --autolaunch`, because of the following sequence
of events:

* one test-case (/gapplication/basic in my testing) calls g_test_dbus_up()

* that test-case (/gapplication/basic in my testing) calls g_test_dbus_down()
  which calls g_test_dbus_unset() which does a:
  g_unsetenv (DBUS_SESSION_BUS_ADDRESS);
  g_unsetenv (DISPLAY);

* a subsequent test-case (/gapplication/no-appid in my testing)
  does something that tries to connect to the session bus

* because DBUS_SESSION_BUS_ADDRESS has been unset, we use a default code
  path, which is to run dbus-launch --autolaunch

Then we go into a reasonably complicated fork/exec which for some reason
is failing on mipsel; it might be something to do with g_spawn_sync()
for dbus-launch in the GDBus thread, concurrently with
g_spawn_async_with_pipes() in the main thread. I think there's still a
bug here, but the interaction between GApplication and GDBus doesn't seem
ike the simplest possible place to debug that...

Anyway, we can make this test pass by not attempting autolaunch, which I
think should be probably applied anyway, even at the risk of masking the
g_spawn_sync() vs. g_spawn_async_with_pipes() bug.

I haven't upstreamed this patch or committed it to pkg-gnome svn yet.

S
From 9f40e2066733662c8bf9ff801eb9acf29bae401b Mon Sep 17 00:00:00 2001
From: Simon McVittie s...@debian.org
Date: Mon, 3 Feb 2014 01:14:45 +
Subject: [PATCH] Do not attempt to autolaunch a session dbus-daemon with no
 DISPLAY

The two known use-cases for autolaunching are:

* X-forwarding: ssh -Y myhost myapp resulting in a
  session bus on myhost but an X server on the original host

* Legacy desktop environments on OSs without D-Bus integration:
  e.g. running a single GNOME or KDE app under fvwm or something,
  without a session dbus-daemon being started by either systemd,
  gnome-session, or OS integration scripts analogous to Debian's
  /etc/X11/Xsession.d/75dbus_dbus-launch

In either case, an X11 DISPLAY is also needed.

dbus-launch --autolaunch doesn't do anything useful when unable
to connect to an X11 display; this has been the case since the feature
was added in 2006, and is useful to avoid split brain situations in
which two processes that ought to be part of the same session end up
on separate session buses. Since dbus commit 407c111 in 2011,
libdbus hasn't even attempted to run dbus-launch --autolaunch
unless getenv(DISPLAY) returns non-null in the parent: this avoids
doing a relatively complicated fork-and-exec that is clearly not
going to lead to success. This commit gives GDBus the same policy.

In Debian, I've encountered GLib test failures in
gio/tests/gapplication.c which appear to be related to the
fork-and-exec for dbus-launch (Debian bug #737380). Specifically,
one test-case ends by calling g_test_dbus_unset(), and the next
test-case tries to access the session bus with DBUS_SESSION_BUS_ADDRESS
unset, resulting in an attempt to autolaunch. Checking for DISPLAY
avoids this attempt to autolaunch, since g_test_dbus_unset() also
unsets DISPLAY. It seems likely that there is some orthogonal bug here,
perhaps involving g_spawn_sync() in the GDBus thread racing with
g_spawn_async_with_pipes() in the main thread, but GApplication is
probably not the ideal place to debug that.

In my opinion as D-Bus maintainer, dbus-launch --autolaunch should
be considered to be an X11 feature, and any future D-Bus enhancements
(e.g. kdbus) or successors for X11 (e.g. Wayland, Mir) should obtain
a session bus address by other means - either a session manager
such as systemd --user, gnome-session or Upstart, or a wrapper
for the user session like dbus-run-session(1).

Related to dbus bug https://bugs.freedesktop.org/show_bug.cgi?id=19997.

Bug: [FIXME: upstream this]
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737380
---
 gio/gdbusaddress.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gio/gdbusaddress.c b/gio/gdbusaddress.c
index ef807f6..bd37890 100644
--- a/gio/gdbusaddress.c
+++ b/gio/gdbusaddress.c
@@ -1038,6 +1038,13 @@ get_session_address_dbus_launch (GError **error)
   goto out;
 }
 
+  if (g_getenv (DISPLAY) == NULL)
+{
+  g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
+   _(Cannot autolaunch D-Bus without X11 $DISPLAY));
+  goto out;
+}
+
   /* We're using private libdbus facilities here. When everything
* (X11, Mac OS X, Windows) is spec'ed out correctly (not even the
* X11 property is correctly documented right now) we should
-- 
1.9.rc1