GNOME Bugzilla – Bug 791744
gmenumodel test sometimes fails: assertion failed (items_changed_count == 1): (0 == 1)
Last modified: 2017-12-21 10:52:06 UTC
On Debian's reproducible builds infrastructure, we've seen one of the gmenumodel tests failing like this: 1..11 # Start of gmenu tests ok 1 /gmenu/equality PASS: gmenumodel 1 /gmenu/equality ok 2 /gmenu/random PASS: gmenumodel 2 /gmenu/random ok 3 /gmenu/attributes PASS: gmenumodel 3 /gmenu/attributes ok 4 /gmenu/links PASS: gmenumodel 4 /gmenu/links ok 5 /gmenu/mutable PASS: gmenumodel 5 /gmenu/mutable ok 6 /gmenu/convenience PASS: gmenumodel 6 /gmenu/convenience ok 7 /gmenu/menuitem PASS: gmenumodel 7 /gmenu/menuitem # Start of dbus tests ok 8 /gmenu/dbus/roundtrip PASS: gmenumodel 8 /gmenu/dbus/roundtrip # GLib-GIO:ERROR:../../../../../gio/tests/gmenumodel.c:850:test_dbus_subscriptions: assertion failed (items_changed_count == 1): (0 == 1) ERROR: gmenumodel - too few tests run (expected 11, got 8) ERROR: gmenumodel - exited with status 134 (terminated by signal 6?) This is in test /gmenu/dbus/subscriptions, which connects to the items-changed signal, appends 3 items to an empty menu, triggers a subscription to D-Bus signals, runs the main loop for 100ms, and asserts that there has been one items-changed event and the menu now has 3 items. So this looks like some timing issue: something (another parallel build?) is slowing down the test enough that 100ms is not long enough to wait. I've asked whether the reproducible builds infrastructure builds and tests multiple packages in parallel on the same hardware. This test should ideally wait for the expected events to happen (and optionally assert that the time elapsed is less than some arbitrary maximum) instead of waiting an arbitrary time and asserting that the expected events happened. That would often be quicker, too. Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884661
Created attachment 365712 [details] [review] gmenumodel test: If something goes wrong, don't wait forever I'm about to add some loops that would otherwise wait indefinitely.
Created attachment 365714 [details] [review] gmenumodel test: Wait for the expected events to happen Previously, we waited an arbitrary 100ms or 200ms and then asserted that the events had happened, but that might fail if the machine is slow or heavily loaded. We still wait for an arbitrary time for negative tests (asserting that no more signals are received) because we don't have any way to do better here.
Review of attachment 365712 [details] [review]: Yup.
Review of attachment 365714 [details] [review]: Looks good, thanks.
Pushed to master, thanks. Would it be useful to you if they were also backported to glib-2-54? Attachment 365712 [details] pushed as ea159a9 - gmenumodel test: If something goes wrong, don't wait forever Attachment 365714 [details] pushed as 8fef0a9 - gmenumodel test: Wait for the expected events to happen
(In reply to Philip Withnall from comment #5) > Pushed to master, thanks. Would it be useful to you if they were also > backported to glib-2-54? Yes, but the backport for the first one is non-trivial, because this test was refactored between 2.54 and 2.55 to add the peer mode. I'll attach what I used in Debian.
Created attachment 365743 [details] [review] [2.54] gmenumodel test: If something goes wrong, don't wait forever --- Very similar to Attachment #365712 [details], but the timeout being created and destroyed is in a different function.
Created attachment 365744 [details] [review] [2.54] gmenumodel test: Wait for the expected events to happen --- Essentially the same as Attachment #365714 [details], but patching a different function.
Review of attachment 365743 [details] [review]: OK.
Review of attachment 365744 [details] [review]: OK.
Pushed to glib-2-54; thanks for the backports.