GTK+ Forums

Discussion forum for GTK+ and Programming. Ask questions, troubleshoot problems, view and post example code, or express your opinions.
It is currently Sat Nov 22, 2014 5:43 pm

All times are UTC




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: memory leaks in gtk3 code
PostPosted: Sat Jun 01, 2013 11:12 am 
Offline
GTK+ Guru

Joined: Sun Jul 08, 2012 3:14 pm
Posts: 107
Location: Coventry, UK
Hello friends,
I am trying check memory leaks in my code, and valgrind is showing many error. As I have never used valgrind before, I need help.
To start with, I am concentrating to the default gtk call's.
as coded, memory is leaked from mkbib.c's line number 140. But line number 140 is just

Code:
gtk_init(&argc, &argv);


I have used
Code:
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 --log-file=vgdump --suppressions=gtk.suppression ./mkbib


which, along with gtk.suppression is taken from https://live.gnome.org/Valgrind

Code:
==28420== 16 bytes in 1 blocks are definitely lost in loss record 2,413 of 10,955
==28420==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==28420==    by 0x310CA4D68E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x311C611176: ??? (in /usr/lib64/libatk-bridge-2.0.so.0.0.0)
==28420==    by 0x311C60C19D: atk_bridge_adaptor_init (in /usr/lib64/libatk-bridge-2.0.so.0.0.0)
==28420==    by 0x311D50257B: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38D6FA: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x310CA52FB6: g_option_context_parse (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x311D38DBCD: gtk_parse_args (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC28: gtk_init_check (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC58: gtk_init (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x403F65: main (mkbib.c:140)
==28420==
==28420== 16 bytes in 1 blocks are definitely lost in loss record 2,414 of 10,955
==28420==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==28420==    by 0x310CA4D68E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x311C611176: ??? (in /usr/lib64/libatk-bridge-2.0.so.0.0.0)
==28420==    by 0x311C60C1DD: atk_bridge_adaptor_init (in /usr/lib64/libatk-bridge-2.0.so.0.0.0)
==28420==    by 0x311D50257B: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38D6FA: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x310CA52FB6: g_option_context_parse (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x311D38DBCD: gtk_parse_args (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC28: gtk_init_check (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC58: gtk_init (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x403F65: main (mkbib.c:140)
==28420==
==28420== 24 bytes in 1 blocks are possibly lost in loss record 3,468 of 10,955
==28420==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==28420==    by 0x310CA4D68E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x310CA63F65: g_memdup (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x310D22D274: ??? (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420==    by 0x310D22DFCC: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420==    by 0x311D5022C7: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311A6154C8: atk_add_focus_tracker (in /usr/lib64/libatk-1.0.so.0.20609.1)
==28420==    by 0x311D502567: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38D6FA: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x310CA52FB6: g_option_context_parse (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x311D38DBCD: gtk_parse_args (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC28: gtk_init_check (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC58: gtk_init (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x403F65: main (mkbib.c:140)
==28420==
==28420== 24 bytes in 1 blocks are possibly lost in loss record 3,469 of 10,955
==28420==    at 0x4A06B6F: calloc (vg_replace_malloc.c:593)
==28420==    by 0x310CA4D6E6: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x310D22DF00: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420==    by 0x310D22DD4E: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420==    by 0x310D21E7BF: g_param_spec_flags (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420==    by 0x311D4C27BB: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x310D22E0B5: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.3400.2)
==28420==    by 0x311D5022C7: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311A6154C8: atk_add_focus_tracker (in /usr/lib64/libatk-1.0.so.0.20609.1)
==28420==    by 0x311D502567: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38D6FA: ??? (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x310CA52FB6: g_option_context_parse (in /usr/lib64/libglib-2.0.so.0.3400.2)
==28420==    by 0x311D38DBCD: gtk_parse_args (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC28: gtk_init_check (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x311D38DC58: gtk_init (in /usr/lib64/libgtk-3.so.0.600.4)
==28420==    by 0x403F65: main (mkbib.c:140)

I have found some discussion that valgrind is not good to detect memory leaks in gtk. is this one of such cases, that I should ignore? or I am missing something?

my system involved is:
    gtk3-devel-3.6.4-1.fc18.x86_64
    valgrind-3.8.1-9.fc18.x86_64
    gcc (GCC) 4.7.2 20121109

Also, probably more importantly, how I can suppress those system call error may be what I am looking for.


Top
 Profile  
 
 Post subject: Re: memory leaks in gtk3 code
PostPosted: Sat Jun 01, 2013 4:22 pm 
Offline
Never Seen the Sunlight

Joined: Mon Apr 28, 2008 5:52 am
Posts: 777
Location: UK
Hi,

Valgrind has its uses. GTK+ is pretty lazy when it comes to allocating and deallocating internal buffers needed for the life time of the application. For example it may allocate an area of memory for a lookup table during initialisation which is needed for the life of the application. GTK+ will then never deallocate this. To Valgrind this looks like a memory leak, (which technically it is) but as an optimisation GTK+ does not deallocate it as it will be deallocated during application exit and so not an error. This is why you need suppression files so that Valgrind can ignore these. The problem is that you will need to change these with most GTK+ version changes.

You can create you own suppression file yourself. I have never done this myself. The application that I work on requires real time processing of audio and Valgrind slows everything down too much to be of any use to me. Like all tools you do need to choose the right one and use it in the correct way. Note that there are other memory profiling systems out there though not all as flexible as Valgrind and GLib has some very very basic profiling built in.

Documentation on supression files :-http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress and http://valgrind.org/docs/manual/faq.html#faq.writesupp

_________________
E.


Top
 Profile  
 
 Post subject: Re: memory leaks in gtk3 code
PostPosted: Sat Jun 01, 2013 6:54 pm 
Offline
GTK+ Guru

Joined: Sun Jul 08, 2012 3:14 pm
Posts: 107
Location: Coventry, UK
errol,
Thanks for your reply.

Generating suppression file looks tedious (my valgrind log file is huge.)
To understand if I really need to concern, attached below is the valgrind summary for a full run.
Should I really need to be concerned (it only leaks 16kB+19kB)

Code:
==18286== LEAK SUMMARY:
==18286==    definitely lost: 16,393 bytes in 48 blocks
==18286==    indirectly lost: 19,136 bytes in 595 blocks
==18286==      possibly lost: 1,356,053 bytes in 6,847 blocks
==18286==    still reachable: 2,047,350 bytes in 13,473 blocks
==18286==         suppressed: 0 bytes in 0 blocks
==18286==
==18286== For counts of detected and suppressed errors, rerun with: -v
==18286== ERROR SUMMARY: 1927 errors from 1927 contexts (suppressed: 2 from 2)


Top
 Profile  
 
 Post subject: Re: memory leaks in gtk3 code
PostPosted: Sat Jun 01, 2013 7:49 pm 
Offline
Never Seen the Sunlight

Joined: Mon Apr 28, 2008 5:52 am
Posts: 777
Location: UK
That looks about right in terms of the amount of memory that is left over. There is a lot of references to various blocks which could be suppressed and make the error log easier to sift through and to to what you want.

Looking at the Gnome web web the suppression file is for GTK+ 2.12

The GIT repository has a GTK+ v3 suppression which can be made. This could be of use for you.
https://github.com/dtrebbien/GNOME.supp

_________________
E.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group