From: <bug...@wi...> - 2003-09-09 14:14:32
|
Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugzilla.gnome.org/show_bug.cgi?id=119456 Changed by th...@ma.... --- shadow/119456 Sat Aug 30 02:48:48 2003 +++ shadow/119456.tmp.23218 Tue Sep 9 10:14:01 2003 @@ -32,13 +32,13 @@ ------- Additional Comments From ds...@sc... 2003-08-21 04:43 ------- Created an attachment (id=19402) patch -------- Additional Comments From th...@ur... 2003-08-26 06:41 ------- +------- Additional Comments From th...@ap... 2003-08-26 06:41 ------- postponing to next release until this gets looked in to properly ------- Additional Comments From ds...@sc... 2003-08-26 12:40 ------- The patch merely gets rid of an incorrect warning. Functionally, the code is identical. @@ -50,6 +50,23 @@ It should definitely be applied to 0.6.3. ------- Additional Comments From ds...@sc... 2003-08-30 02:47 ------- *** Bug 113323 has been marked as a duplicate of this bug. *** + +------- Additional Comments From th...@ma... 2003-09-09 10:13 ------- +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) + |