Bug#738290: glib2.0/exp: FTBFS on mips: gdbus-close-pending.c: Stream has outstanding operation

[Simon McVittie]

Source: glib2.0
Version: 2.38.2-3
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=723788

Continuing the saga of "can we make GLib 2.38 build on all architectures?":

gdbus-close-pending.c is a regression test for GNOME bug 651268, which was that
close() in the main thread raced with write() or flush() in the GDBus thread.
However, it appears to have its own race condition, so far seen once, on a mips
autobuilder:

FAIL: gdbus-close-pending
=========================
# random seed: R02Sc2942a140521364046646a1a66f824a9
# Start of gdbus tests
**
GLib-GIO:ERROR:/«PKGBUILDDIR»/./gio/tests/gdbus-close-pending.c:353:test_once:
assertion failed (f->error == NULL): Stream has outstanding operation
(g-io-error-quark, 20)
#
GLib-GIO:ERROR:/«PKGBUILDDIR»/./gio/tests/gdbus-close-pending.c:353:test_once:
assertion failed (f->error == NULL): Stream has outstanding operation
(g-io-error-quark, 20)
Aborted

This means that the g_dbus_connection_close_sync() failed with that error.

I thought this was a simple case of "the main thread might race with the GDBus
thread", but on closer inspection of how I fixed Bug #651268, all the actual
I/O should be happening in the GDBus thread now; so I don't actually know how
this situation can arise. Any ideas?

I'm also very tempted to force the regression tests to run with "make -j1"
so they're less likely to hit obscure race conditions on our slower
architectures. At the moment, the mips buildd is using make -j2.
Fixing test cases that have race conditions is A Good Thing, but
so is unblocking GNOME 3.10.

    S