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 684182 - Memory leak with delegate callback parameters in async methods
Memory leak with delegate callback parameters in async methods
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Code Generator: GAsync
unspecified
Other All
: Normal blocker
: ---
Assigned To: Vala maintainers
Vala maintainers
: 683921 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-09-17 08:17 UTC by Heiher
Modified: 2013-06-04 20:50 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
a simple test case. (544 bytes, text/x-vala)
2012-09-17 08:17 UTC, Heiher 		Details
a smaller test case for analysis (249 bytes, text/plain)
2013-04-08 02:09 UTC, Richard Schwarting 		Details

Description Heiher 2012-09-17 08:17:38 UTC 
Created attachment 224477 [details]
a simple test case.

This is a simple test case.
Comment 1 Heiher 2012-09-17 08:18:35 UTC 
*** Bug 683921 has been marked as a duplicate of this bug. ***
Comment 2 cee1 2012-09-25 01:17:02 UTC 
I can produce it, with "export G_MESSAGES_DEBUG=all", I observed the execution of constructor, but no execution of the destructor.
Comment 3 Richard Schwarting 2013-04-08 02:09:01 UTC 
Created attachment 240917 [details]
a smaller test case for analysis

I think it's the same bug.

In this simple test case, which can be run with 

valac -g -C --pkg gio-2.0  bugtest1.vala
gcc `pkg-config --cflags --libs glib-2.0 gio-2.0` -g -o bugtest1 bugtest1.c
G_SLICE=always-malloc valgrind --leak-check=full ./bugtest1  2>&1 | less

You can see the memory leak at:
==29487== 24 bytes in 1 blocks are definitely lost in loss record 116 of 285
==29487==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==29487==    by 0x317F44D68E: g_malloc (gmem.c:159)
==29487==    by 0x317F4627F1: g_slice_alloc (gslice.c:1003)
==29487==    by 0x317F462D45: g_slice_alloc0 (gslice.c:1029)
==29487==    by 0x3180030084: g_type_create_instance (gtype.c:1870)
==29487==    by 0x3180014A37: g_object_constructor (gobject.c:1854)
==29487==    by 0x31800164F0: g_object_newv (gobject.c:1637)
==29487==    by 0x400D24: async_function (bugtest1.c:48)
==29487==    by 0x400F8D: _vala_main (bugtest1.vala:7)
==29487==    by 0x400FD6: main (bugtest1.vala:5)

When the GSimpleAsyncResult is created in my async_function (line 48 in the .c), it's given a meaningless source:
    _data_->_async_result = g_simple_async_result_new (g_object_newv (G_TYPE_OBJECT, 0, NULL), _callback_, _user_data_, async_function); 

And that source is never unref'd. ;_;
Comment 4 Luca Bruno 2013-04-08 07:03:49 UTC 
Please tell valac --version .
Comment 5 Heiher 2013-06-04 01:06:50 UTC 
Vala 0.20.1
Comment 6 Heiher 2013-06-04 01:09:05 UTC 
G_MESSAGES_DEBUG=all ./async-block
** (process:400): DEBUG: async-block.vala:8: ObjA


** (process:400): DEBUG: async-block.vala:12: ~ObjA (not print)
Comment 7 Luca Bruno 2013-06-04 20:50:48 UTC 
commit e60d03f2f93bb33652768957c8304c4e3e0f4d85
Author: Luca Bruno <lucabru@src.gnome.org>
Date:   Tue Jun 4 22:46:23 2013 +0200

    Fix memory leak when defining async functions targeting glib < 2.20.
    
    Fixes bug 684182

You should be able to workaround the problem until next release by targeting a newer glib with --target-glib 2.20 .