GNOME Bugzilla – Bug 755496
glib 2.46 fails GStreamer test suite
Last modified: 2017-04-10 22:09:23 UTC
Since glib 2.46, the GStreamer core test suite (1.4.5 or 1.5.91) fails: Running suite(s): Controller 60%: Checks: 25, Failures: 10, Errors: 0 libs/controller.c:357:F:general:controller_interpolation_none:0: Assertion 'gst_control_source_get_value (cs, 0 * GST_SECOND, &v)' failed libs/controller.c:534:F:general:controller_interpolation_unset:0: 'GST_TEST_OBJ (elem)->val_int' (100) is not equal to '50' (50) libs/controller.c:632:F:general:controller_interpolation_linear_absolute_value_array:0: '(raw_values)[0]' (nan) is not equal to '0' (0) libs/controller.c:697:F:general:controller_interpolation_linear_value_array:0: '(raw_values)[0]' (nan) is not equal to '0.0' (0) libs/controller.c:757:F:general:controller_interpolation_linear_invalid_values:0: 'GST_TEST_OBJ (elem)->val_float' (0) is not equal to '100.0' (100) libs/controller.c:825:F:general:controller_interpolation_linear_default_values:0: Assertion 'gst_timed_value_control_source_unset (tvcs, 1 * GST_SECOND)' failed libs/controller.c:879:F:general:controller_interpolation_linear_disabled:0: 'GST_TEST_OBJ (elem)->val_double' (0) is not equal to '20.0' (20) libs/controller.c:1034:F:general:controller_interpolation_linear_before_ts0:0: 'GST_TEST_OBJ (elem)->val_int' (0) is not equal to '100' (100) libs/controller.c:1464:F:general:controller_trigger_exact:0: Assertion 'gst_control_source_get_value (cs, 0 * GST_SECOND, &raw_val)' failed libs/controller.c:1510:F:general:controller_trigger_tolerance:0: 'GST_TEST_OBJ (elem)->val_int' (0) is not equal to '50' (50) FAIL libs/controller (exit status: 10) The set of failing assertions doesn't seem to be stable. Bisected to glib commit d286395 (list store: Fix a parameter check).
I think that commit is bogus. The documentation says that g_sequence_search is supposed to find the position that the element would be inserted in, i.e. find the same position as g_sequence_insert_sorted. After this commit, using g_sequence_search plus g_sequence_iter_prev to find a match (in a sequence without duplicates) is broken (see libs/gst/controller/gsttimedvaluecontrolsource.c:182).
Furthermore, the other use of g_sequence_search at libs/gst/controller/gsttimedvaluecontrolsource.c:237 depends on this exact behavior as well: /** * gst_timed_value_control_source_find_control_point_iter: * @self: the control source to search in * @timestamp: the search key * * Find last value before given timestamp in control point list. * If all values in the control point list come after the given * timestamp or no values exist, %NULL is returned. * * For use in control source implementations. * * Returns: (transfer none): the found #GSequenceIter or %NULL */ GSequenceIter *gst_timed_value_control_source_find_control_point_iter (GstTimedValueControlSource * self, GstClockTime timestamp) { GSequenceIter *iter; if (!self->values) return NULL; iter = g_sequence_search (self->values, ×tamp, (GCompareDataFunc) gst_control_point_find, NULL); /* g_sequence_search() returns the iter where timestamp * would be inserted, i.e. the iter > timestamp, so * we need to get the previous one. And of course, if * there is no previous one, we return NULL. */ if (g_sequence_iter_is_begin (iter)) return NULL; return g_sequence_iter_prev (iter); }
Indeed, the commit message indicates that I meant to commit something else here. The commit was an unsuccessful attempt to improve gsequence for the case you mention: insert-or-find.
Matthias, it would be great if you could give a reference to the commit that fixed a bug :) In this case, it's commit 2d7817887a9f0624f73492d04b2a992545f0beb9
Fix git-bz to insert that automatically, and it'll happen. Otherwise, it probably won't...
oops. https://github.com/irssi/irssi/issues/689