GNOME Bugzilla – Bug 724113
gdbus-connection-loss test can fail on slow machines
Last modified: 2015-05-14 11:43:46 UTC
On a Debian armhf (ARM hardfloat) buildd, we've seen this test failure: FAIL: gdbus-connection-loss =========================== # random seed: R02S9eeebdf75bae6b60e3a4e641457b9aea # Start of gdbus tests ** GLib-GIO:ERROR:/«PKGBUILDDIR»/./gio/tests/gdbus-connection-loss.c:100:test_connection_loss: assertion failed (error == (g-io-error-quark, 18)): GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name com.example.TestService was not provided by any .service files (g-dbus-error-quark, 2) # GLib-GIO:ERROR:/«PKGBUILDDIR»/./gio/tests/gdbus-connection-loss.c:100:test_connection_loss: assertion failed (error == (g-io-error-quark, 18)): GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name com.example.TestService was not provided by any .service files (g-dbus-error-quark, 2) cleaning up pid 17970 Aborted Full log: https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=armhf&ver=2.38.2-3&stamp=1391932830
The test starts by forking gdbus-testserver and waiting 500*1000 µs (0.5s) for it to start: path = g_test_build_filename (G_TEST_BUILT, "gdbus-testserver", NULL); g_assert (g_spawn_command_line_async (path, NULL)); g_free (path); /* wait for the service to come up */ usleep (500 * 1000); If the autobuilder is slow - which these ARM machines probably are - then it might not have taken its well-known bus name by then. This test should wait for the well-known name to exist before proceeding.
Some other arbitrary delays in GIO tests: serials_thread_func() in gdbus-connection.c waits 0.25s for a message to be sent. It should probably loop until get_last_serial() returns nonzero, perhaps with some fairly long timeout. gdbus-threading.c waits 0.5s for gdbus-testserver to start. It should do the same as gdbus-connection-loss. pollable.c has a suspicious-looking usleep but I'm not sure how that test works.
Created attachment 268789 [details] [review] gdbus tests: wait up to 60s for gdbus-testserver to take its bus name Previously, we waited up to 0.5s, but that can fail on slow architectures like ARM; now we wait up to 60s in 0.1s increments. --- Tested on GLib 2.38, with and without a hack in gdbus-testserver to make it sleep for 2 seconds on startup. Not tested on GLib 2.39 yet.
Created attachment 268790 [details] [review] gdbus-connection: wait up to 10s to actually send a message We previously waited 0.25s, which should be enough even on slow machines, but you never know; but we also now wait in 0.1s increments, so this test should actually be faster now. --- Same testing as the other patch.
(In reply to comment #2) > pollable.c has a suspicious-looking usleep but I'm not sure how that test > works. I'm not going to address this one for now; I haven't seen it fail "in real life".
Reproducible on a Debian mipsel porterbox, which is similarly slow, in 2/100 runs.
(In reply to comment #6) > Reproducible on a Debian mipsel porterbox, which is similarly slow, in 2/100 > runs. (Sorry, wrong bug.)
Review of attachment 268789 [details] [review]: I noticed that our first upload of glib into Ubuntu with this patch started causing the testsuite to fail inside gdbus-threading thusly: Running test: /usr/share/installed-tests/glib/gdbus-threading.test # random seed: R02Sbe207b20df867c52237a5d9d9675d687 # Start of gdbus tests ** GLib-GIO:ERROR:/build/buildd/glib2.0-2.40.0/./gio/tests/gdbus-threading.c:207:test_delivery_in_thread_func: assertion failed: (data.signal_count == 1) # GLib-GIO:ERROR:/build/buildd/glib2.0-2.40.0/./gio/tests/gdbus-threading.c:207:test_delivery_in_thread_func: assertion failed: (data.signal_count == 1) I have reworked the patch to break this out into a function in gdbus-tests.c which is instead called from the two tests you touched with this patch. I'm going to attach it now. ::: gio/tests/gdbus-threading.c @@ -594,3 @@ - /* wait for the service to come up */ - usleep (500 * 1000); Removing this sleep means that we have a race getting gdbus-testserver on the bus
Created attachment 273326 [details] [review] gdbus tests: wait up to 60s for gdbus-testserver to take its bus name Previously, we waited up to 0.5s, but that can fail on slow architectures like ARM; now we wait up to 60s in 0.1s increments. Patch originally by Simon McVittie <simon.mcvittie@collabora.co.uk>, modified by Iain Lane to be called earlier, to catch all testcases in a particular test.
Does anyone object to these year-old test fixes or shall I just merge them? Iain's revised version of my first patch looks good to me.
Merge them, please.
Comment on attachment 268790 [details] [review] gdbus-connection: wait up to 10s to actually send a message 3beb67f9f3b1db6ee133973edfd89df89d7bdde5, 2.45.2
Comment on attachment 273326 [details] [review] gdbus tests: wait up to 60s for gdbus-testserver to take its bus name fe1a2dc1965b564727480c8a99740252ea81274b, 2.45.2
(In reply to Matthias Clasen from comment #11) > Merge them, please. Fixed in git for 2.45.2. Thanks!