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 698260 - Rygel leaks memory
Rygel leaks memory
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: D-Bus
0.18.x
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2013-04-18 07:37 UTC by Nirbheek Chauhan
Modified: 2014-06-15 10:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Rygel valgrind log (gzipped) (63.53 KB, application/x-gzip)
2013-04-18 07:39 UTC, Nirbheek Chauhan
  Details
Fix memory leak in Rygel.DescriptionFile (871 bytes, patch)
2013-04-18 07:40 UTC, Nirbheek Chauhan
committed Details | Review

Description Nirbheek Chauhan 2013-04-18 07:37:40 UTC
While running Rygel overnight, I noticed that its memory usage shot up to 300MB (RSS), and kept increasing as I browsed my playlists from my phone. To debug this, I ran it under valgrind and got a leak summary. The command I ran was:

G_SLICE=always-malloc G_DEBUG=gc-friendly libtool --mode=execute valgrind --suppressions=$PATH_TO/gstreamer-1.0.2/common/gst.supp --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=30 --log-file=valgrind.log ./src/rygel/rygel -c /etc/rygel.conf

This leak summary is with the External and MPRIS backends enabled.

Also attached is a patch to fix a leak in Rygel.DescriptionFile.modify_service_type().
Comment 1 Nirbheek Chauhan 2013-04-18 07:39:45 UTC
Created attachment 241797 [details]
Rygel valgrind log (gzipped)
Comment 2 Nirbheek Chauhan 2013-04-18 07:40:37 UTC
Created attachment 241798 [details] [review]
Fix memory leak in Rygel.DescriptionFile

This patch fixes one of the leaks.
Comment 3 Jens Georg 2013-04-18 08:12:48 UTC
Review of attachment 241798 [details] [review]:

Crap. Stupid manual memory management in libxml. Thanks
Comment 4 Jens Georg 2013-04-18 08:31:28 UTC
The other stuff looks a bit like issues with Vala's DBus support or GDBus itself
Comment 5 Jens Georg 2014-06-14 15:51:47 UTC
yeah, the generated proxy is not freeing the variants when translating to GHashTable

	_tmp18_ = g_hash_table_new_full (g_str_hash, g_str_equal, g_free, NULL);
	g_variant_iter_init (&_tmp19_, _inner_reply);
	while (g_variant_iter_loop (&_tmp19_, "{?*}", &_tmp20_, &_tmp21_)) {
		g_hash_table_insert (_tmp18_, g_variant_dup_string (_tmp20_, NULL), g_variant_get_variant (_tmp21_));
	}
	_result = _tmp18_;

Note the "NULL" passed as GDestroyNotify for value, but g_variant_get_variant is [transfer full], so it actually should be g_variant_unref
Comment 7 Luca Bruno 2014-06-15 10:01:10 UTC
commit 0edb05ca26693d9a0b0fa1b4e547b58990ea0db4
Author: Luca Bruno <lucabru@src.gnome.org>
Date:   Sun Jun 15 11:36:56 2014 +0200

    gvariant module: Fix memory leak when deserializing hashtables with gvariant
    
    Fixes bug 698260

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.