GNOME Bugzilla – Bug 745326
yield in async function using SoupSession.queue_message leaks context data
Last modified: 2018-05-22 15:21:42 UTC
Created attachment 298153 [details] Test case The attached test case generates a "DownloadData" struct that it allocates using g_slice_new0, that never gets freed. Here's the valgrind output, using G_SLICE=always-malloc valgrind --leak-check=full --show-possibly-lost=no --log-file=vgdump ./test2 ==25001== Memcheck, a memory error detector ==25001== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==25001== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==25001== Command: ./test2 ==25001== Parent PID: 24965 ==25001== ==25001== ==25001== HEAP SUMMARY: ==25001== in use at exit: 867,993 bytes in 5,736 blocks ==25001== total heap usage: 166,273 allocs, 160,537 frees, 24,848,168 bytes allocated ==25001== ==25001== 171 (96 direct, 75 indirect) bytes in 1 blocks are definitely lost in loss record 2,574 of 2,723 ==25001== at 0x4C29F90: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==25001== by 0x57CDBF9: g_malloc (gmem.c:97) ==25001== by 0x57B0A0D: g_slice_alloc (gslice.c:1007) ==25001== by 0x57B0A4C: g_slice_alloc0 (gslice.c:1032) ==25001== by 0x54EEDC7: g_type_create_instance (gtype.c:1852) ==25001== by 0x5508628: g_object_new_internal.lto_priv.634 (gobject.c:1774) ==25001== by 0x550534B: g_object_newv (gobject.c:1922) ==25001== by 0x55081D9: g_object_new (gobject.c:1614) ==25001== by 0x522A100: g_io_module_new (giomodule.c:355) ==25001== by 0x522A450: g_io_modules_scan_all_in_directory_with_scope (giomodule.c:488) ==25001== by 0x522B02E: _g_io_modules_ensure_loaded (giomodule.c:1064) ==25001== by 0x522AB27: _g_io_module_get_default (giomodule.c:837) ==25001== ==25001== 176 (72 direct, 104 indirect) bytes in 1 blocks are definitely lost in loss record 2,581 of 2,723 ==25001== at 0x4C29F90: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==25001== by 0x57CDBF9: g_malloc (gmem.c:97) ==25001== by 0x57B0A0D: g_slice_alloc (gslice.c:1007) ==25001== by 0x57B0A4C: g_slice_alloc0 (gslice.c:1032) ==25001== by 0x400E01: download (test2.c:52) ==25001== by 0x401160: _vala_main (test2.vala:17) ==25001== by 0x4011D1: main (test2.vala:14) ==25001== ==25001== LEAK SUMMARY: ==25001== definitely lost: 168 bytes in 2 blocks ==25001== indirectly lost: 179 bytes in 2 blocks ==25001== possibly lost: 13,628 bytes in 246 blocks ==25001== still reachable: 821,762 bytes in 5,252 blocks ==25001== suppressed: 0 bytes in 0 blocks ==25001== Reachable blocks (those to which a pointer was found) are not shown. ==25001== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==25001== ==25001== For counts of detected and suppressed errors, rerun with: -v ==25001== ERROR SUMMARY: 235 errors from 235 contexts (suppressed: 0 from 0) (The first one is a known problem in GModule and can be ignored)
On closer inspection, this seems to be happening because the closure passed to queue_message did not call download.callback, doing that makes the leak go away. Should valac complain about the fact that the callback does not get called or rather ignore that and free the context data another way?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME'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.gnome.org/GNOME/vala/issues/490.