[gst-devel] patch gstelement.c?

[Wim Taymans]

On Sat, 2002-03-23 at 04:18, Jim Thornton wrote:
> Ok, this one is more of a question:
> 
> If you do a gst_object_destroy of an object that is in a bin before you 

The idea was not to unref/destroy objects you don't have a reference to.
> gst_object_destroy the bin, the parent pointer gets cleared (in 
> gst_object_dispose) but the object (element) gets left in the bin children 
> list causing havoc later when you try to gst_object_destroy the bin 
> itself.  Ok, maybe you are only supposed to ever call gst_object_destroy 
> on a top-level thing, or call gst_bin_remove manually, but this doesn't 

You should call gst_bin_remove, yes (I think this is even so in Gtk+). 

> seem right to me.  I tried adding the following to gst_element_dispose:
> 
> 1495a1498,1501
> >   /* remove ourselves from containing bin */
> >   if (gst_element_get_parent(element)) {
> >     gst_bin_remove(GST_BIN_CAST(gst_element_get_parent(element)), 
> element);
> >   }
> 
> and that sure does the trick.  The problem is that now I'm getting 
> 
> (process:14959): GThread-ERROR **: file gthread-posix.c: line 226 
> (g_cond_free_posix_impl): error 'Device or resource busy' during 
> 'pthread_cond_destroy ((pthread_cond_t *) cond)'
> aborting...
> Abort
> 
> out of the g_cond_free() (I believe) in the end of gst_element_dispose.

yes, this usually happens when you free a conditional or mutex that is
locked (not sure why it is locked though).

Wim

PS. nice patches, I'll try to apply them.
> 
> 
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> 
>