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 719472 - leak in generated proxy-side property-setter
leak in generated proxy-side property-setter
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gdbus
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2013-11-28 08:46 UTC by Dirk-Jan C. Binnema
Modified: 2013-11-28 13:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test program showing the leak (1.19 KB, application/gzip)
2013-11-28 08:46 UTC, Dirk-Jan C. Binnema
  Details
patch for codegen that seems to plug the leak (1.39 KB, patch)
2013-11-28 08:51 UTC, Dirk-Jan C. Binnema
committed Details | Review

Description Dirk-Jan C. Binnema 2013-11-28 08:46:13 UTC
Created attachment 263005 [details]
test program showing the leak

It seems that using the gdbus-codegen-generated property-setter leaks a GVariant in the proxy; I'm seeing the following (I've attached a test program that isolates the problem). If you run the setter in a loop you can actually see the memory go up in, say, top.

==27988== Memcheck, a memory error detector
==27988== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==27988== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==27988== Command: ./client
==27988== Parent PID: 4137
==27988==
==27988==
==27988== HEAP SUMMARY:
==27988==     in use at exit: 117,048 bytes in 1,263 blocks
==27988==   total heap usage: 3,823 allocs, 2,560 frees, 214,644 bytes allocated
==27988==
==27988== 40 bytes in 1 blocks are definitely lost in loss record 400 of 801
==27988==    at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==27988==    by 0x3DF924EE6E: g_malloc (gmem.c:104)
==27988==    by 0x3DF9264FAD: g_slice_alloc (gslice.c:1016)
==27988==    by 0x3DF928187D: g_variant_new_from_children (gvariant-core.c:478)
==27988==    by 0x3DF927ED96: g_variant_builder_end (gvariant.c:3654)
==27988==    by 0x3DF92805A2: g_variant_valist_new (gvariant.c:4624)
==27988==    by 0x3DF9280906: g_variant_new_va (gvariant.c:4778)
==27988==    by 0x3DF9280A34: g_variant_new (gvariant.c:4717)
==27988==    by 0x4CFB925: decode_method_reply (gdbusconnection.c:5366)
==27988==    by 0x4D0044D: g_dbus_connection_call_done (gdbusconnection.c:5478)
==27988==    by 0x4CAD786: g_simple_async_result_complete (gsimpleasyncresult.c:777)
==27988==    by 0x4CAD7E8: complete_in_idle_cb (gsimpleasyncresult.c:789)
==27988==    by 0x3DF92492A5: g_main_context_dispatch (gmain.c:3066)
==27988==    by 0x3DF9249627: g_main_context_iterate.isra.24 (gmain.c:3713)
==27988==    by 0x3DF9249A39: g_main_loop_run (gmain.c:3907)
==27988==    by 0x402FF9: main (in /data/source/gdbus/test/client)
==27988==
==27988== LEAK SUMMARY:
==27988==    definitely lost: 40 bytes in 1 blocks
==27988==    indirectly lost: 0 bytes in 0 blocks
==27988==      possibly lost: 7,612 bytes in 142 blocks
==27988==    still reachable: 98,812 bytes in 1,045 blocks
==27988==         suppressed: 0 bytes in 0 blocks
==27988== Reachable blocks (those to which a pointer was found) are not shown.
Comment 1 Dirk-Jan C. Binnema 2013-11-28 08:51:10 UTC
Created attachment 263006 [details] [review]
patch for codegen that seems to plug the leak

Comparing the code generated for the setter and other methods without (real) return value, I noticed that the setter does not unref the gvariant it gets.

So, I made the following change to the code-generator (codegen.py), and the leak seems to go away.
Comment 2 Colin Walters 2013-11-28 13:23:57 UTC
Review of attachment 263006 [details] [review]:

Right.