After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 119456 - [PATCH] assertion `GST_IS_SCHEDULER (sched)' failed
[PATCH] assertion `GST_IS_SCHEDULER (sched)' failed
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.6.2
Other Linux
: Normal normal
: 0.6.4
Assigned To: David Schleef
GStreamer Maintainers
: 113323 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-08-08 21:37 UTC by David Schleef
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (921 bytes, patch)
2003-08-21 08:43 UTC, David Schleef
none Details | Review
Suggested fix for the reported warning. (509 bytes, patch)
2003-09-09 14:38 UTC, Jan Schmidt
none Details | Review

Description David Schleef 2003-08-08 21:37:53 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.
Comment 1 David Schleef 2003-08-21 08:42:07 UTC
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.
Comment 2 David Schleef 2003-08-21 08:43:40 UTC
Created attachment 19402 [details] [review]
patch
Comment 3 Thomas Vander Stichele 2003-08-26 10:41:49 UTC
postponing to next release until this gets looked in to properly
Comment 4 David Schleef 2003-08-26 16:40:19 UTC
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.

Comment 5 David Schleef 2003-08-30 06:47:59 UTC
*** Bug 113323 has been marked as a duplicate of this bug. ***
Comment 6 Jan Schmidt 2003-09-09 14:13:59 UTC
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)
Comment 7 Jan Schmidt 2003-09-09 14:38:07 UTC
Created attachment 19826 [details] [review]
Suggested fix for the reported warning.
Comment 8 David Schleef 2003-09-25 01:26:19 UTC
How does the thread get dereferenced if you take out that line?
Comment 9 David Schleef 2003-09-25 01:32:29 UTC
Er, and it causes a g_warning() instead of a g_return_if_fail().

First patch (19402) applied to 0.6.
Comment 10 David Schleef 2003-10-09 18:45:58 UTC
No really.  It's applied now.
Comment 11 Jan Schmidt 2003-10-10 13:23:51 UTC
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?
Comment 12 David Schleef 2003-10-10 17:56:30 UTC
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.