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 100563 - object lifecycle is unclear/buggy
object lifecycle is unclear/buggy
Status: VERIFIED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.4.2
Other Linux
: Normal normal
: 0.4.0
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-12-06 21:10 UTC by david
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test code (1.30 KB, text/plain)
2002-12-06 21:14 UTC, david
Details
debug output (ansi) (6.53 KB, text/plain)
2002-12-06 21:15 UTC, david
Details

Description david 2002-12-06 21:10:12 UTC
After creating a simple pipeline with a filesrc->vorbisdec->osssink and
playing back a song, I am unable to manually clean up the gstreamer objects
I created from my program. The reason this is a problem for me is that I
need to dynamically connect/disconnect elements, put them in different
pipelines, and reuse them at different times, so I can't just destroy the
pipeline when I'm finished.

Attached is sample source code for 0.4.2 and the relevant part of the debug
output (with an all-inclusive debug mask).
Comment 1 david 2002-12-06 21:14:19 UTC
Created attachment 12803 [details]
test code
Comment 2 david 2002-12-06 21:15:29 UTC
Created attachment 12804 [details]
debug output (ansi)
Comment 3 Thomas Vander Stichele 2002-12-07 18:47:16 UTC
Hi,

it would help if you could
a) give the error you get
b) provide a bt if it's a segfault
c) attach a --gst-mask=-1 log

as for the code itself, not sure why you want to do it like that.  A
gst_object_unref (bin) would probably do all you want there.
Comment 4 david 2002-12-31 00:32:06 UTC
The reason why I needed to do this is because my pipelines change
dynamically and single elements are added/destroyed frequently without
destroying or otherwise modifying the rest of the pipeline.

wtay cleared up the lifecycle concepts one day on IRC, so I now know
that calling gst_bin_remove() automatically destroys the removed
element (unless the application manually reparents it). Before I was
trying to manually destroy the elements. Since I wasn't familiar with
the gtk lifecycle I didn't nkow that's how it works in gst.

If necessary, I can help out with the docs, including info like this
that someone with no gst experience would need.