GNOME Bugzilla – Bug 740292
base_src_do_sync: GLib-GObject-CRITICAL reffing clock when seeking really excessively
Last modified: 2016-02-21 23:51:22 UTC
when seeking really quickly in my app, i sometimes observed GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed i could reproduce this after about 40 seek operations on an mkv file within 30 seconds. i got a backtrace: (enigma2:2623): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed (enigma2:2623): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed Program received signal SIGTRAP, Trace/breakpoint trap.
+ Trace 234336
Thread 1612026944 (LWP 2658)
(gdb) when continuing, it goes on with (enigma2:2623): GStreamer-CRITICAL **: gst_object_unref: assertion `((GObject *) object)->ref_count > 0' failed (enigma2:2623): GStreamer-CRITICAL **: gst_clock_get_time: assertion `GST_IS_CLOCK (clock)' failed and a couple more (enigma2:2623): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed and (enigma2:2623): GStreamer-CRITICAL **: gst_object_unref: assertion `((GObject *) object)->ref_count > 0' failed to eventually segfault out none of my proprietary elements is messing with the clock.
Hi Andreas, Is it happening with all mkv files? or with a specific file? i have been testing seek with playback-test for mkv files and i dont get this error even after playing with seek for a long time. Can you check with playback-test and verify once. And is it possible to attach complete logs. It may give some more information about the issue. Thanks
Hi Vineeth, i may have filed this a little prematurely. I tried again with other files, and it happens even with .avi files so it's certainly not a matroskademux issue at all. i've observed that when playing with gst-play-1.0, i could only reproduce this when using our proprietary sink element, i think it has to do with latency queries. i'll try this with more locks first
According to IRC discussions, this only happens with your custom sink, or do you have a test case using GStreamer sinks? What element's clock is chosen as the pipeline clock in your pipeline?
Created attachment 291339 [details] GST_DEBUG_FILE=/testProgs/bug740292_clockref.log GST_DEBUG=*CLOCK*:6 GST_DEBUG_NO_COLOR=1 gst-play-1.0 /media/hdd/movie/testcd/J_SUBTITLES /SUB-01.avi --interactive it's true, this issue only happens with dreamvideosink, a decoding hardware sink element. due to the lack of other actual video sinks on the architecture, i could only test against fakesink and filesink, where i couldn't reproduce the problem. none of the hw sink elements can provide a clock, therefore the pipeline uses the system clock.
Not really clear the problem is in GStreamer then, not sure what to do about this, you'll have to debug it :) Please re-open if you find it's something in gst.