Re: Debugging memleaks - valgrind suppressions & closures

[Phil Clayton <phil clayton lineone net>]

On 07/11/12 22:49, marcin saepia net wrote:
> I've noticed that a lot of "possibly lost" stack traces are related to
> signals/closures:
>
> ==2893== 72 bytes in 1 blocks are possibly lost in loss record 6,781 of 9,985
> ==2893==    at 0x4C29DB4: calloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==2893==    by 0x5912AE0: g_malloc0 (gmem.c:189)
> ==2893==    by 0x5127B18: g_closure_new_simple (gclosure.c:206)
> ==2893==    by 0x512907F: g_cclosure_new (gclosure.c:917)
> ==2893==    by 0x51400CD: g_signal_connect_data (gsignal.c:2443)
> ==2893==    by 0x619E7AF: soup_session_init (in
> /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1.5.0)
> ==2893==    by 0x5149907: g_type_create_instance (gtype.c:1884)
> ==2893==    by 0x512E0B8: g_object_constructor (gobject.c:1849)
> ==2893==    by 0x512F6E3: g_object_newv (gobject.c:1713)
> ==2893==    by 0x512FEC5: g_object_new_valist (gobject.c:1830)
> ==2893==    by 0x61A0AEA: soup_session_async_new_with_options (in
> /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1.5.0)
> ==2893==    by 0x12718556: gst_soup_http_src_start (in
> /usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstsouphttpsrc.so)
>
>
> ==2893== 72 bytes in 1 blocks are possibly lost in loss record 6,771 of 9,985
> ==2893==    at 0x4C29DB4: calloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==2893==    by 0x5912AE0: g_malloc0 (gmem.c:189)
> ==2893==    by 0x5127B18: g_closure_new_simple (gclosure.c:206)
> ==2893==    by 0x512907F: g_cclosure_new (gclosure.c:917)
> ==2893==    by 0x5133258: g_cclosure_new_object (gobject.c:3739)
> ==2893==    by 0x5132ACA: g_signal_connect_object (gobject.c:3561)
> ==2893==    by 0x41F83E: myapp_base_constructor (source-base.c:4016)
> ==2893==    by 0x422B97: myapp_net_http_constructor (source-net-http.c:531)
> ==2893==    by 0x512F6E3: g_object_newv (gobject.c:1713)
> ==2893==    by 0x512FEC5: g_object_new_valist (gobject.c:1830)
> ==2893==    by 0x51301D3: g_object_new (gobject.c:1545)
> ==2893==    by 0x422648: myapp_net_http_construct (source-net-http.c:353)
>
> I actually use signals to facilitate interactions between objects. My
> suspicion is that closures can be somehow related to memleak. Am I
> right?

In creating GTK+ bindings for SML with (supposedly) automatic memory 
management, I found a subtle way that memory was being leaked and no 
obvious neat solution.  It may be completely unrelated to your issue but 
I mention it because the symptoms appear similar - closures and objects 
that were not unreferenced.  (However, I don't know anything about 
Vala's automatic memory management so don't know if this is an issue for 
Vala.  As far as I can see, it is an issue when using ref/unref from 
garbage collector hooks where the garbage collector uses normal 
reachability analysis.)

The issue occurs when a callback function F is called via a closure C 
that is connected to a signal of an object A where
1. the body of F explicitly refers to A
2. A is an object that does not receive a destroy signal, e.g. 
GtkTextBuffer.
Then, the callback is not automatically disconnected from A as there is 
no destroy signal by 2, so C is not unref'd.  Without unref'ing C, F is 
not unref'd.  By 1, A is not unref'd.  I.e. there is a cycle
  A -> C -> F -> A
Unfortunately, the reachability analysis performed by the garbage 
collector doesn't see this cycle.  Effectively we just have
  C -> F -> A
The garbage collector doesn't know that C still exists just because a 
signal is connected in A.

(My current work-around is to have a 'ChildSignal' abstraction, where a 
signal connection also specifies a parent object derived from GtkWidget 
and the signal is disconnected by the parent's destroy signal.)

Maybe this helps explain the issue.  If it doesn't, I'd be interested to 
know how other systems with automatic memory management solve the above 
issue.

Phil