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 683094 - gclosure: valgrind reports possible lost blocks for g_closure_new_simple()
gclosure: valgrind reports possible lost blocks for g_closure_new_simple()
Status: RESOLVED NOTABUG
Product: glib
Classification: Platform
Component: gobject
2.29.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-08-31 11:48 UTC by Claudio Saavedra
Modified: 2012-09-12 06:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Claudio Saavedra 2012-08-31 11:48:41 UTC 
I'm running ephy under valgrind and I see *lots* of these warnings.

==21821== 72 bytes in 1 blocks are possibly lost in loss record 8,099 of 13,040
==21821==    at 0x4A06F18: calloc (vg_replace_malloc.c:566)
==21821==    by 0x8D7C4CB: standard_calloc (gmem.c:104)
==21821==    by 0x8D7C567: g_malloc0 (gmem.c:189)
==21821==    by 0x8CD8B6B: g_closure_new_simple (gclosure.c:206)
==21821==    by 0x8CDACB7: g_cclosure_new (gclosure.c:917)
==21821==    by 0x8CF4EEA: g_signal_connect_data (gsignal.c:2447)


Checking at the code, it doesn't seem to be a bug (the unref method takes care of freeing the real closure, but I am not sure so I file it anyway.
Comment 1 Alexander Larsson 2012-09-05 09:51:35 UTC 
It might be valgrind not grokking that we're keeping a pointer into the block but none to the first address of the block.
Comment 2 Claudio Saavedra 2012-09-12 06:19:24 UTC 
I'll close this then. I hope we add this to the glib suppressions file (bug 666114).