I am using 'Valgrind' memory leak check However, I do not know the meaning.

[ForestPoem]

I am using 'Valgrind' memory leak check However, I do not know the meaning.

Many memory leak log. But let me give up.

==7948== 1 bytes in 1 blocks are possibly lost in loss record 3 of 6,123
==7948== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7948== by 0x725AA38: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.4)
==7948== by 0x726F2AD: g_strdup (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.4)
==7948== by 0xDAEA2E0: g_dbus_connection_signal_subscribe (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.3200.4)
==7948== by 0x10D1DCF0: ??? (in /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so)
==7948== by 0x10D1E086: ??? (in /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so)
==7948== by 0x7254D12: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.4)
==7948== by 0x725505F: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.4)
==7948== by 0x7255459: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.4)
==7948== by 0x10D1D98A: ??? (in /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so)
==7948== by 0x72769B4: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.4)
==7948== by 0x5FD9E99: start_thread (pthread_create.c:308)
==7948==
==7948== 1 bytes in 1 blocks are possibly lost in loss record 4 of 6,123
==7948== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7948== by 0x725AA38: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.4)
==7948== by 0x726F2AD: g_strdup (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.4)
==7948== by 0x7BFBC8B: g_param_spec_string (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948== by 0xE35A117: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==7948== by 0x7C0B5F6: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948== by 0x7BF3CAB: g_object_newv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948== by 0x7BF41EB: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948== by 0xE35871F: gtk_settings_get_for_screen (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==7948== by 0xE307268: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==7948== by 0x7BF0353: g_cclosure_marshal_VOID__OBJECTv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948== by 0x7BECEC9: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948==
==7948== 1 bytes in 1 blocks are possibly lost in loss record 6 of 6,123
==7948== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7948== by 0x725AA38: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.4)
==7948== by 0x726F2AD: g_strdup (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.4)
==7948== by 0x7BFBC8B: g_param_spec_string (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948== by 0xE2DD1B3: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==7948== by 0x7C0B5F6: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948== by 0x7BF3CAB: g_object_newv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948== by 0x7BF41EB: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948== by 0xE2DFB38: gtk_label_new (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==7948== by 0xE3BACA6: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==7948== by 0xE3BAF87: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==7948== by 0x7BECCA1: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948==
==7948== 1 bytes in 1 blocks are possibly lost in loss record 7 of 6,123
==7948== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7948== by 0x725AA38: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.4)
==7948== by 0x726F2AD: g_strdup (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.4)
==7948== by 0x7BFBC8B: g_param_spec_string (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948== by 0xE3F72FF: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==7948== by 0x7C0B5F6: g_type_class_ref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948== by 0x7BF3CAB: g_object_newv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948== by 0x7BF41EB: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948== by 0xE267701: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==7948== by 0xE267B17: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==7948== by 0x7C0D926: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948== by 0x7BF20B8: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.4)
==7948==

I used the function not directly. Don't know how to do it.

[jsulm]

These could be false positives.
Did you do it like this: valgrind --leak-check=yes PATH_TO_BINARY

[ForestPoem]

@jsulm

your solution to the same result.

[jsulm]

Did you build your application in debug mode?
As I mentioned with Valgrind you often get false positives.

[ForestPoem]

@jsulm

I was mistaken. should have checked the Definitely logs.