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 794316 - Gst.Pipeline never disposes Gst.Bus
Gst.Pipeline never disposes Gst.Bus
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-sharp
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-03-14 07:47 UTC by Justin Kim
Modified: 2018-11-03 11:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Pipeline: Call Dispose to Gst.Bus (824 bytes, patch)
2018-03-14 07:57 UTC, Justin Kim
reviewed Details | Review
Bin: Call Dispose for child elements (967 bytes, patch)
2018-03-14 07:59 UTC, Justin Kim
none Details | Review

Description Justin Kim 2018-03-14 07:47:52 UTC
To explain leakages, I created unit tests in my personal repository.

https://github.com/justinjoy/Gst.Tests/blob/master/Gst.Tests/PipelineTests.cs

There are 4 tests;

 - TestPipelineDispose: disposing of pipeline instance only (Test failed)
 - TestPieplineParseAndDispose: same as above, but the pipeline is created by Parser.Launch (Test failed)
 - TestPipelineDisposeManually: Explictly calling 'Dispose' for all exising element (Test passed)
 - TestPieplineUriDecodebinForcedlyDispose: Almost same as above, but disposing of child elements in 'deep-element-removed' callback. (Test passed)


So what I found is that the binding causes leakages as long as a programmer doesn't manage Gst.Element, currently. But, still I am not sure if they should be managed in gstreamer-sharp, or application.

I'll add some patches to make my unit tests pass successfully.
Comment 1 Justin Kim 2018-03-14 07:57:49 UTC
Created attachment 369646 [details] [review]
Pipeline: Call Dispose to Gst.Bus

When Gst.Pipeline is disposing, its internal Gst.Bus should be unreffed too.
However, I am not sure if managing the instance of Gst.Bus is an application's responsibility.
Comment 2 Sebastian Dröge (slomo) 2018-03-14 07:58:10 UTC
> But, still I am not sure if they should be managed in gstreamer-sharp, or application.

Simple rule of thumb: in C# you should never have to worry about memory leaks unless you yourself keep a reference to something around.
Comment 3 Sebastian Dröge (slomo) 2018-03-14 07:59:24 UTC
Review of attachment 369646 [details] [review]:

::: sources/custom/Pipeline.cs
@@ +29,3 @@
+		{
+			this.Bus.Dispose ();
+			base.Dispose(disposed);

That this fixes it would suggest that the C# Bus wrapper object is leaked somehow, and with this fix the native GstBus would be disposed but the C# wrapper object stays around.
Comment 4 Justin Kim 2018-03-14 07:59:59 UTC
Created attachment 369647 [details] [review]
Bin: Call Dispose for child elements
Comment 5 Justin Kim 2018-03-14 08:24:09 UTC
(In reply to Sebastian Dröge (slomo) from comment #2)
> > But, still I am not sure if they should be managed in gstreamer-sharp, or application.
> 
> Simple rule of thumb: in C# you should never have to worry about memory
> leaks unless you yourself keep a reference to something around.

Yes, in theory, I don't need to care about leakage. However, managed objects never been disposed while running application so it consumes memory gradually. That's the point to make me confused.
Comment 6 GStreamer system administrator 2018-11-03 11:09:01 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-sharp/issues/3.