GNOME Bugzilla – Bug 119456
[PATCH] assertion `GST_IS_SCHEDULER (sched)' failed
Last modified: 2004-12-22 21:47:04 UTC
rhythmbox HEAD causes this assertion failure when changing from one song to the next. (rhythmbox:11290): GStreamer-CRITICAL **: file gstscheduler.c: line 179 (gst_scheduler_pad_unlink): assertion `GST_IS_SCHEDULER (sched)' failed This bug is a reminder for me to look into it.
This is caused by gst_bin_unset_element_sched() being called with sched==NULL. Presumably, since there is another check for sched==NULL in the function, NULL is a valid value for sched. However, I don't really understand the code. The following patch adds another check in the correct place.
Created attachment 19402 [details] [review] patch
postponing to next release until this gets looked in to properly
The patch merely gets rid of an incorrect warning. Functionally, the code is identical. The code that is currently there is clearly wrong. With the patch, it is less wrong (and doesn't display warnings), and may even be correct. However, the function is undocumented, so I don't know how it is _supposed_ to be called. It should definitely be applied to 0.6.3.
*** Bug 113323 has been marked as a duplicate of this bug. ***
It seems to me that the problem is that gstthread sets sched to null before calling the inherited dispose function. The GstBin dispose function attempts to remove all its children from the scheduler, but the appropriate GstElement->sched pointer has been set to NULL in gst_thread_dispose. I think the correct solution is that the scheduler on a bin should not be changed without ensuring that all children get the same scheduler set. In which case, setting the scheduler to NULL in gst_thread_dispose without changing the children is invalid, and should not be done until after gst_bin_dispose has run (at which point it is unnecessary, as gst_element_dispose already unrefs the scheduler and sets it NULL)
Created attachment 19826 [details] [review] Suggested fix for the reported warning.
How does the thread get dereferenced if you take out that line?
Er, and it causes a g_warning() instead of a g_return_if_fail(). First patch (19402) applied to 0.6.
No really. It's applied now.
DS: drat, I only just saw the points from 24/9, and you're not on IRC the sched gets unreferenced because the gstthread is a gstelement, and gstelement unrefs the scheduler when disposing. I don't see any g_warning with my patch, which one did you see? I don't think the gstbin.c fix is correct, because it won't clear the 'sched' reference in the child elements, even though they've been removed from their bin, will it?
The code in gstbin.c is clearly wrong, and the patch "happens" to silence the warning that is the subject of this bug. There may be leakages and/or reference counting problems, but I am not concerned about that in 0.6.