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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org