Re: Debugging memleaks - valgrind suppressions & closures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/11/12 22:49, marcin@xxxxxxxxxx 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

_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list


[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux