Bug 20975 - GLib.DBusConnection.CallSync() is leaking the reply
Summary: GLib.DBusConnection.CallSync() is leaking the reply
Status: NEW
Alias: None
Product: Gtk#
Classification: Mono
Component: gtk-sharp ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2014-06-30 05:11 UTC by Xavier Claessens
Modified: 2014-06-30 07:34 UTC (History)
1 user (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
patch (1.80 KB, patch)
2014-06-30 05:46 UTC, Xavier Claessens
Details
Memory leak test case (476 bytes, text/x-csharp)
2014-06-30 06:21 UTC, Jo Shields
Details
Updated testcase (597 bytes, text/x-csharp)
2014-06-30 07:34 UTC, Xavier Claessens
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report for Bug 20975 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
NEW

Description Xavier Claessens 2014-06-30 05:11:53 UTC
g_dbus_connection_call_sync() returns a strong ref on the reply GVariant. The generated code does:

  new GLib.Variant(raw_ret);

Which internally does a g_variant_ref_sink() and since the GVariant is not floating that adds a 2nd ref on it. When the managed code decide to dispose the variant, it does a single g_variant_unref() and it gets leaked. CallFinish() has the same issue AFAIK.
Comment 1 Xavier Claessens 2014-06-30 05:13:09 UTC
Also related to this: If the call fails it will return null but the generated code will still try to create a new GLib.Variant for it, leading to some g_warning().
Comment 2 Xavier Claessens 2014-06-30 05:46:56 UTC
Created attachment 7232 [details]
patch
Comment 3 Jo Shields 2014-06-30 06:21:45 UTC
Created attachment 7233 [details]
Memory leak test case

Xavier's first patch does not fix the problem for me.

Attached is a memory-eating test case, which will bring machines without much RAM to their knees within seconds. Looks like each iteration of CallSync leaks about a meg of RAM.
Comment 4 Xavier Claessens 2014-06-30 07:15:15 UTC
Looks like there is a 2nd problem: Variant is a IDisposable so they always have to be wrapped inside a using() statement. With your testcase Variant::Dispose() is never called.
Comment 5 Xavier Claessens 2014-06-30 07:34:01 UTC
Created attachment 7234 [details]
Updated testcase

It seems that all objects coming from glib# or gio# must be wrapper with 'using'. With my patch this new testcase seems to not leak.