For short time I started to learn GTK-3.0 and I started to create a GUI for a program I work.
The program compiles fine with no warnings but when I run it with valgrind I see a lot of memory leaks and I can't figure out what I'm doing Wrong here.
I reduced my program to a minimal code which make it easy for you to explain the problem.
To following code compiles fine but with lots of memory leaks:
#include <gtk/gtk.h>
int main(int argc, char *argv[]){
gtk_init(&argc, &argv);
GtkWidget *window;
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(window, "delete-event", G_CALLBACK(gtk_main_quit), NULL);
gtk_widget_show(window);
gtk_main();
}
I compile it with:
gcc -Wpedantic -std=c11 -Wall -Wextra -Werror -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wconversion -Wshadow -Winit-self -Wfloat-equal -Wwrite-strings -O0 -g main.c -o app `pkg-config --cflags gtk+-3.0 ` `pkg-config --libs gtk+-3.0 `
and after I run valgrind with the following command:
valgrind --leak-check=full --track-origins=yes --leak-check=full ./app
I get the following Output:
==14405== Memcheck, a memory error detector
==14405== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==14405== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==14405== Command: ./app
==14405==
==14405==
==14405== HEAP SUMMARY:
==14405== in use at exit: 1,243,902 bytes in 12,774 blocks
==14405== total heap usage: 80,535 allocs, 67,761 frees, 6,190,649 bytes allocated
==14405==
==14405== 16 bytes in 1 blocks are possibly lost in loss record 1,279 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5796522: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AF90: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x577A30B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774177: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 16 bytes in 1 blocks are possibly lost in loss record 1,280 of 5,945
==14405== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x4C2FDEF: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E27E7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5796406: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AF90: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x577A30B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774177: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 16 bytes in 1 blocks are possibly lost in loss record 1,281 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5796522: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AF90: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x577A371: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774177: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 16 bytes in 1 blocks are possibly lost in loss record 1,282 of 5,945
==14405== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x4C2FDEF: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E27E7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5796406: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AF90: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x577A371: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774177: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 16 bytes in 1 blocks are possibly lost in loss record 1,283 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5796522: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AF90: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5783B04: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774181: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 16 bytes in 1 blocks are possibly lost in loss record 1,284 of 5,945
==14405== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x4C2FDEF: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E27E7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5796406: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AF90: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5783B04: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774181: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 16 bytes in 1 blocks are possibly lost in loss record 1,285 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5796522: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AF90: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x577EC1B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774186: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 16 bytes in 1 blocks are possibly lost in loss record 1,286 of 5,945
==14405== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x4C2FDEF: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E27E7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5796406: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AF90: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x577EC1B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774186: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 24 bytes in 1 blocks are possibly lost in loss record 1,808 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x57993B5: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5798E2C: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5788147: g_param_spec_flags (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5191F6F: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x579922C: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x4EBFC49: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x7532A1D: atk_add_focus_tracker (in /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0.21809.1)
==14405== by 0x4EC0084: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x5778FA4: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x578AFC0: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405==
==14405== 32 bytes in 1 blocks are possibly lost in loss record 2,824 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x57993B5: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5798E2C: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5788057: g_param_spec_enum (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5FCBAFE: ??? (in /usr/lib/x86_64-linux-gnu/libgdk-3.so.0.1800.9)
==14405== by 0x579922C: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5798E2C: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x57803A3: g_object_new_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5780520: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5FF16DD: ??? (in /usr/lib/x86_64-linux-gnu/libgdk-3.so.0.1800.9)
==14405== by 0x5FF3E21: ??? (in /usr/lib/x86_64-linux-gnu/libgdk-3.so.0.1800.9)
==14405==
==14405== 56 bytes in 1 blocks are possibly lost in loss record 3,553 of 5,945
==14405== at 0x4C2FD5F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E27E7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x57959D8: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579B2CC: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x577A53D: g_flags_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x50A2D0A: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x4FB9264: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x579922C: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x57803A3: g_object_new_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5780520: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x4FBAAB7: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x4FBAE82: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405==
==14405== 80 bytes in 1 blocks are possibly lost in loss record 4,221 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x57993B5: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5798E2C: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579C247: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x57840D2: g_param_spec_internal (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5788661: g_param_spec_object (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5FD1231: ??? (in /usr/lib/x86_64-linux-gnu/libgdk-3.so.0.1800.9)
==14405== by 0x579922C: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x577FDAC: g_object_newv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5780533: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5FD1324: gdk_display_manager_get (in /usr/lib/x86_64-linux-gnu/libgdk-3.so.0.1800.9)
==14405==
==14405== 96 bytes in 1 blocks are possibly lost in loss record 5,132 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5795A59: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5795B43: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x57740AA: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 96 bytes in 1 blocks are possibly lost in loss record 5,133 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5795A59: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5795B43: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AF82: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x577A30B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774177: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 96 bytes in 1 blocks are possibly lost in loss record 5,134 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5795A59: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5795B43: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AF82: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x577A371: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774177: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 96 bytes in 1 blocks are possibly lost in loss record 5,135 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5795A59: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5795B43: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AF82: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5783B04: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774181: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 96 bytes in 1 blocks are possibly lost in loss record 5,136 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5795A59: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5795B43: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AF82: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x577EC1B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774186: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 132 bytes in 1 blocks are possibly lost in loss record 5,413 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5796DFF: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AFE0: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x577A30B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774177: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 132 bytes in 1 blocks are possibly lost in loss record 5,414 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5796DFF: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AFE0: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x577A371: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774177: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 148 bytes in 1 blocks are possibly lost in loss record 5,457 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5796BD6: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AFE0: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5783B04: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774181: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 148 bytes in 1 blocks are possibly lost in loss record 5,458 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2780: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x5796BD6: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579AFE0: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x577EC1B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5774186: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 176 bytes in 4 blocks are possibly lost in loss record 5,513 of 5,945
==14405== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2728: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x4FA7173: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x4FA7439: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x4FA622C: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x4F02766: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x4F03FE4: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x4F0425D: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x577E896: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x57801B4: g_object_new_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5780520: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x4F02D27: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405==
==14405== 184 bytes in 1 blocks are possibly lost in loss record 5,528 of 5,945
==14405== at 0x4C2FD5F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E27E7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x57959D8: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x579B2CC: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5785799: g_param_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5787AFB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x577418B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==14405== by 0x40105FA: call_init (dl-init.c:30)
==14405== by 0x40105FA: _dl_init (dl-init.c:120)
==14405== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==14405==
==14405== 200 bytes in 5 blocks are possibly lost in loss record 5,549 of 5,945
==14405== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x86E2728: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x86FB537: g_memdup (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x4FA7109: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x4FA7387: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x4FA61EC: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x50EFD11: gtk_style_context_set_state (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x4F03EE4: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x4F0425D: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9)
==14405== by 0x577E896: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x57801B4: g_object_new_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405== by 0x5780520: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.1)
==14405==
==14405== 336 bytes in 1 blocks are possibly lost in loss record 5,673 of 5,945
==14405== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14405== by 0x40136D4: allocate_dtv (dl-tls.c:322)
==14405== by 0x40136D4: _dl_allocate_tls (dl-tls.c:539)
==14405== by 0x59C42AE: allocate_stack (allocatestack.c:588)
==14405== by 0x59C42AE: pthread_create##GLIBC_2.2.5 (pthread_create.c:539)
==14405== by 0x87218AF: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x8703E9E: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x8703F57: g_thread_new (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x86DE280: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1)
==14405== by 0x8392E16: g_task_get_type (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4800.1)
==14405== by 0x83F0610: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4800.1)
==14405== by 0x83E4216: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4800.1)
==14405==
==14405==
==14405== LEAK SUMMARY:
==14405== definitely lost: 0 bytes in 0 blocks
==14405== indirectly lost: 0 bytes in 0 blocks
==14405== possibly lost: 3,544 bytes in 35 blocks
==14405== still reachable: 1,160,006 bytes in 12,091 blocks
==14405== of which reachable via heuristic:
==14405== length64 : 4,080 bytes in 72 blocks
==14405== newarray : 2,112 bytes in 52 blocks
==14405== suppressed: 0 bytes in 0 blocks
==14405== Reachable blocks (those to which a pointer was found) are not shown.
==14405== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==14405==
==14405== For counts of detected and suppressed errors, rerun with: -v
==14405== ERROR SUMMARY: 28 errors from 28 contexts (suppressed: 0 from 0)
After I read a book and followed the GTK3 Manual and I just can figure out where is the leak here.
Did I started wrong with the GUI here? From the manual I'm almost sure that I code it in the right way.
I see in the valgrind output that calloc and realloc was called, this means that it should be a free() call needed too.
How do I release that memory with GTK+, if I must do it?
This has been answered here many times. This is what I gave as an answer to someone else who asked this on a forum that I used to moderate:
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.
What you are seeing are false positives. You can use a suppression file so that valgrind can ignore these. You can create your own or search for one already done.
Related
Could someone suggest a fix for this problem?
When I use import_array(), Valgrind reports memory leak of 157528 bytes.
Here is the small piece of code to replicate the problem on Ubuntu16.04 and Python3.5
#include <Python.h>
#include "numpy/arrayobject.h"
int main(int argc, char *argv[])
{
Py_Initialize();
import_array();
Py_Finalize();
return 0;
}
Here are the relevant pieces of Valgrind report.
==85642== **2,689** bytes in 2 blocks are definitely lost in loss record 1,044 of 1,100
==85642== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==85642== by 0x4ED9777: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x505C42B: PyBytes_FromStringAndSize (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x786FE34: arr_add_docstring (compiled_base.c:1415)
==85642== by 0x4EE8038: PyCFunction_Call (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FF41B4: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FF4638: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x5084CAB: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x5084D82: PyEval_EvalCodeEx (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FEC9CA: PyEval_EvalCode (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FF967C: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4EE8038: PyCFunction_Call (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== **154,839** bytes in 81 blocks are definitely lost in loss record 1,099 of 1,100
==85642== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==85642== by 0x4ED9777: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4EA81D8: PyUnicode_New (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4EABFDC: _PyUnicode_FromASCII (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FA073C: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4EE8038: PyCFunction_Call (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FF41B4: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FF4638: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x5084CAB: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x5084D82: PyEval_EvalCodeEx (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FEC9CA: PyEval_EvalCode (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== by 0x4FF967C: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0)
==85642== LEAK SUMMARY:
==85642== definitely lost: 157,528 bytes in 83 blocks
==85642== indirectly lost: 0 bytes in 0 blocks
==85642== possibly lost: 158,183 bytes in 89 blocks
==85642== still reachable: 1,730,311 bytes in 3,551 blocks
==85642== suppressed: 0 bytes in 0 blocks
==85642==
==85642== For counts of detected and suppressed errors, rerun with: -v
==85642== ERROR SUMMARY: 2768 errors from 123 contexts (suppressed: 0 from 0)
I run valgrind-3.10.0 to search for memory leaks in my fortran program. I'm using gfortran-4.9.0 to compile on OS X 10.9.5. From what I can tell from the below output, the memory leak is in a gfortran library. Am I correct? If so, is there anything that I can do?
HEAP SUMMARY:
==30650== in use at exit: 25,727 bytes in 390 blocks
==30650== total heap usage: 34,130 allocs, 33,740 frees, 11,306,357 bytes allocated
==30650==
==30650== Searching for pointers to 390 not-freed blocks
==30650== Checked 9,113,592 bytes
==30650==
==30650== 72 (36 direct, 36 indirect) bytes in 1 blocks are definitely lost in loss record 52 of 84
==30650== at 0x47E1: malloc (vg_replace_malloc.c:300)
==30650== by 0x345AB0: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0x345CF6: __i2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0x34362E: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0x36A8A9: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0x3912DA: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0x376F66: _vsnprintf (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0x376FC5: vsnprintf_l (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0x3674DC: snprintf (in /usr/lib/system/libsystem_c.dylib)
==30650== by 0xE2F6D: write_float (in /usr/local/gfortran/lib/libgfortran.3.dylib)
==30650== by 0xE53A4: _gfortrani_write_real (in /usr/local/gfortran/lib/libgfortran.3.dylib)
==30650== by 0x3FA9999999999999: ???
==30650==
==30650== LEAK SUMMARY:
==30650== definitely lost: 36 bytes in 1 blocks
==30650== indirectly lost: 36 bytes in 1 blocks
==30650== possibly lost: 0 bytes in 0 blocks
==30650== still reachable: 316 bytes in 7 blocks
==30650== suppressed: 25,339 bytes in 381 blocks
==30650== Reachable blocks (those to which a pointer was found) are not shown.
==30650== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==30650==
==30650== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 15 from 15)
--30650--
--30650-- used_suppression: 34 OSX109:6-Leak /usr/local/lib/valgrind/default.supp:797 suppressed: 13,656 bytes in 252 blocks
--30650-- used_suppression: 1 OSX109:1-Leak /usr/local/lib/valgrind/default.supp:747 suppressed: 2,064 bytes in 1 blocks
--30650-- used_suppression: 13 OSX109:7-Leak /usr/local/lib/valgrind/default.supp:808 suppressed: 7,181 bytes in 78 blocks
--30650-- used_suppression: 11 OSX109:10-Leak /usr/local/lib/valgrind/default.supp:839 suppressed: 1,669 bytes in 29 blocks
--30650-- used_suppression: 10 OSX109:9-Leak /usr/local/lib/valgrind/default.supp:829 suppressed: 609 bytes in 15 blocks
--30650-- used_suppression: 5 OSX109:5-Leak /usr/local/lib/valgrind/default.supp:787 suppressed: 144 bytes in 5 blocks
--30650-- used_suppression: 1 OSX109:3-Leak /usr/local/lib/valgrind/default.supp:765 suppressed: 16 bytes in 1 blocks
==30650==
==30650== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 15 from 15)
This could very well be a bug in the gfortran library.
Your best bet would be to reduce this to a self-contained test case and report it to the gfortran developers at fortran#gcc.gnu.org or to submit a bug report at http://www.gnu.org/bugzilla .
I am using valgrind on a program which runs an infinite loop.
As memcheck displays the memory leaks after the end of the program, but as my program has infinite loop it will never end.
So is there any way i can forcefully dump the data from valgrind time to time.
Thanks
Have a look at the client requests feature of memcheck. You can probably use VALGRIND_DO_LEAK_CHECK or similar.
EDIT:
In response to the statement above that this doesn't work. Here is an example program which loops forever:
#include <valgrind/memcheck.h>
#include <unistd.h>
#include <cstdlib>
int main(int argc, char* argv[])
{
while(true) {
char* leaked = new char[1];
VALGRIND_DO_LEAK_CHECK;
sleep(1);
}
return EXIT_SUCCESS;
}
When I run this in valgrind, I get an endless output of new leaks:
$ valgrind ./a.out
==16082== Memcheck, a memory error detector
==16082== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==16082== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==16082== Command: ./a.out
==16082==
==16082== LEAK SUMMARY:
==16082== definitely lost: 0 bytes in 0 blocks
==16082== indirectly lost: 0 bytes in 0 blocks
==16082== possibly lost: 0 bytes in 0 blocks
==16082== still reachable: 1 bytes in 1 blocks
==16082== suppressed: 0 bytes in 0 blocks
==16082== Reachable blocks (those to which a pointer was found) are not shown.
==16082== To see them, rerun with: --leak-check=full --show-reachable=yes
==16082==
==16082== 1 bytes in 1 blocks are definitely lost in loss record 2 of 2
==16082== at 0x4C2BF77: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16082== by 0x4007EE: main (testme.cc:9)
==16082==
==16082== LEAK SUMMARY:
==16082== definitely lost: 1 bytes in 1 blocks
==16082== indirectly lost: 0 bytes in 0 blocks
==16082== possibly lost: 0 bytes in 0 blocks
==16082== still reachable: 1 bytes in 1 blocks
==16082== suppressed: 0 bytes in 0 blocks
==16082== Reachable blocks (those to which a pointer was found) are not shown.
==16082== To see them, rerun with: --leak-check=full --show-reachable=yes
==16082==
==16082== 2 bytes in 2 blocks are definitely lost in loss record 2 of 2
==16082== at 0x4C2BF77: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16082== by 0x4007EE: main (testme.cc:9)
==16082==
==16082== LEAK SUMMARY:
==16082== definitely lost: 2 bytes in 2 blocks
==16082== indirectly lost: 0 bytes in 0 blocks
==16082== possibly lost: 0 bytes in 0 blocks
==16082== still reachable: 1 bytes in 1 blocks
==16082== suppressed: 0 bytes in 0 blocks
==16082== Reachable blocks (those to which a pointer was found) are not shown.
==16082== To see them, rerun with: --leak-check=full --show-reachable=yes
The program does not terminate.
with valgrind 3.7.0, you can trigger (a.o.) leak search from the shell,
using vgdb.
See e.g. http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
(you can do these monitor commands from gdb or from a shell command line, using vgdb).
Use of VALGRIND_DO_LEAK_CHECK (acm answer) works for me.
Remarks :
- Program has to be launch with valgrind (valgrind myProg ...)
- valgrind-devel package has to be installed (to have )
I'm using the command:
valgrind --tool=memcheck --leak-check=yes ./prog
When this runs with a test script, I get no inline error messages or warnings, I just get a Heap Summary and a leak summary.
Am I missing a flag or something?
==31420== HEAP SUMMARY:
==31420== in use at exit: 1,580 bytes in 10 blocks
==31420== total heap usage: 47 allocs, 37 frees, 7,132 bytes allocated
==31420==
==31420== 1,580 (1,440 direct, 140 indirect) bytes in 5 blocks are definitely lost in loss record 2 of 2
==31420== at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==31420== by 0x400FD4: main (lab1.c:51)
==31420==
==31420== LEAK SUMMARY:
==31420== definitely lost: 1,440 bytes in 5 blocks
==31420== indirectly lost: 140 bytes in 5 blocks
==31420== possibly lost: 0 bytes in 0 blocks
==31420== still reachable: 0 bytes in 0 blocks
==31420== suppressed: 0 bytes in 0 blocks
==31420==
==31420== For counts of detected and suppressed errors, rerun with: -v
==31420== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
The last time I used valgrind (a few days ago) it would print out error messages as they occurred, in addition to the heap and leak summaries.
EDIT:
I tried leak-check=full, same result
The line mentioned in the heap summary (lab1.c:51) is:
temp_record = malloc(sizeof(struct server_record));
And I use this pointer pretty often in my code. That is what was so helpful about the valgrind error messages before, they would show me when I would lose my pointer to this malloc or other problems.
Lets say I am using a library that uses glibc. When I exit the program while running it through Valgrind all sorts of memory leaks are detected by Valgrind. I am 100% sure that none of the leaks are explicitly related to my few lines of code I just wrote. Is there a way to suppress leaks from other libraries, and limit the leak detection to your immediate code?
For example:
valgrind --tool=memcheck --leak-check=full --leak-resolution=high \
--log-file=vgdump ./Main
Where the executable was built from the following source:
// Include header files for application components.
#include <QtGui>
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QWidget window;
window.resize( 320,240 );
window.setWindowTitle(
QApplication::translate( "toplevel", "Top-level Widget" ) );
window.show( );
QPushButton button(
QApplication::translate( "childwidget", "Press me"), &window );
button.move( 100, 100 );
button.show( );
int status = app.exec();
return status;
}
Has a log-file that reports the following (large portions removed):
==12803== Memcheck, a memory error detector
==12803== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==12803== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==12803== Command: ./Main
==12803== Parent PID: 12700
==12803==
==12803==
==12803== HEAP SUMMARY:
==12803== in use at exit: 937,411 bytes in 8,741 blocks
==12803== total heap usage: 38,227 allocs, 29,486 frees, 5,237,254 bytes allocated
==12803==
==12803== 1 bytes in 1 blocks are possibly lost in loss record 1 of 4,557
==12803== at 0x402577E: malloc (vg_replace_malloc.c:195)
==12803== by 0xA1DFA4: g_malloc (in /lib/libglib-2.0.so.0.2600.0)
==12803== by 0xA37F29: g_strdup (in /lib/libglib-2.0.so.0.2600.0)
==12803== by 0xB2A6FA: g_param_spec_string (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0x41F36473: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803== by 0xB3D237: g_type_class_ref (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB20B38: g_object_newv (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB212EF: g_object_new (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0x41F34857: gtk_settings_get_for_screen (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803== by 0x41ED0CB6: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803== by 0xB377C7: g_cclosure_marshal_VOID__OBJECT (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB1ABE2: g_closure_invoke (in /lib/libgobject-2.0.so.0.2600.0)
...
==12803== 53,244 bytes in 29 blocks are possibly lost in loss record 4,557 of 4,557
==12803== at 0x402577E: malloc (vg_replace_malloc.c:195)
==12803== by 0xA1DFA4: g_malloc (in /lib/libglib-2.0.so.0.2600.0)
==12803== by 0xA36050: g_slice_alloc (in /lib/libglib-2.0.so.0.2600.0)
==12803== by 0xA36315: g_slice_alloc0 (in /lib/libglib-2.0.so.0.2600.0)
==12803== by 0xB40077: g_type_create_instance (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB1CE35: ??? (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB205C6: g_object_newv (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0xB212EF: g_object_new (in /lib/libgobject-2.0.so.0.2600.0)
==12803== by 0x6180FA3: ??? (in /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so)
==12803== by 0x41F0CDDD: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803== by 0x41F11C24: gtk_rc_get_style (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803== by 0x4200A81F: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2200.0)
==12803==
==12803== LEAK SUMMARY:
==12803== definitely lost: 2,296 bytes in 8 blocks
==12803== indirectly lost: 7,720 bytes in 382 blocks
==12803== possibly lost: 509,894 bytes in 2,908 blocks
==12803== still reachable: 417,501 bytes in 5,443 blocks
==12803== suppressed: 0 bytes in 0 blocks
==12803== Reachable blocks (those to which a pointer was found) are not shown.
==12803== To see them, rerun with: --leak-check=full --show-reachable=yes
==12803==
==12803== For counts of detected and suppressed errors, rerun with: -v
==12803== ERROR SUMMARY: 1364 errors from 1364 contexts (suppressed: 122 from 11)
To ignore Leak errors in all shared libraries under any lib directory (/lib, /lib64, /usr/lib, /usr/lib64, ...), put this in a file and pass it to valgrind with --suppressions=*FILENAME*:
{
ignore_unversioned_libs
Memcheck:Leak
...
obj:*/lib*/lib*.so
}
{
ignore_versioned_libs
Memcheck:Leak
...
obj:*/lib*/lib*.so.*
}
This will probably suffice to limit memcheck reporting to your own code only. However, beware that this will ignore errors caused by any callbacks you wrote that were invoked by the libraries. Catching errors in those callbacks could almost be done with:
{
ignore_unversioned_libs
Memcheck:Leak
obj:*/lib*/lib*.so
...
obj:*/lib*/lib*.so
}
{
ignore_versioned_libs
Memcheck:Leak
obj:*/lib*/lib*.so.*
...
obj:*/lib*/lib*.so.*
}
... but this reveals errors in calls by a library that use the Valgrind malloc. Since valgrind malloc is injected directly into the program text -- not loaded as a dynamic library -- it appears in the stack the same way as your own code does. This allows Valgrind to track the allocations, but also makes it harder to do exactly what you have asked.
FYI: I am using valgrind 3.5.
The above is an excerpt of an answer to an older, slightly different question that is asked in the body text of this question (so title is a little insufficient):
Is it possible to make valgrind ignore certain libraries?
Look up the topic of suppressions at the Valgrind web site; you want to suppress errors from the third party library.