As you may know since the beginning of this year we have for Nim with the compile option --gc:arc a deterministic memory management available (currently only in the devel version of the compiler) which makes it easy to test for memory leaks or corruption. Of course generally there are no leaks or corruptions, as Nim is a high level language, but it is always good to test. So I thought I may do some tests for the Nim GTK bindings.
But before I tried an official C code example, hoping that this would report fine. I took
for first test, as I have a Nim version of that code already, and got
$ gcc `pkg-config gtk+-3.0 --cflags` button.c -o button `pkg-config --libs gtk+-3.0` stefan@nuc /tmp/hhh $ ./button stefan@nuc /tmp/hhh $ valgrind ./button ==5526== Memcheck, a memory error detector ==5526== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==5526== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==5526== Command: ./button ==5526== ==5526== Source and destination overlap in memcpy_chk(0x1ffeffeb20, 0x1ffeffeb20, 32) ==5526== at 0x4845DD7: __memcpy_chk (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5526== by 0x553410E: g_get_language_names_with_category (in /usr/lib64/libglib-2.0.so.0.6200.5) ==5526== by 0x5557A2B: ??? (in /usr/lib64/libglib-2.0.so.0.6200.5) ==5526== by 0x5557B6B: g_key_file_new (in /usr/lib64/libglib-2.0.so.0.6200.5) ==5526== by 0x4B3A06E: gtk_settings_load_from_key_file (in /usr/lib64/libgtk-3.so.0.2404.9) ==5526== by 0x4B3A79C: gtk_settings_init (in /usr/lib64/libgtk-3.so.0.2404.9) ==5526== by 0x54DC7C9: g_type_create_instance (in /usr/lib64/libgobject-2.0.so.0.6200.5) ==5526== by 0x54C522A: ??? (in /usr/lib64/libgobject-2.0.so.0.6200.5) ==5526== by 0x54C5C43: g_object_new_valist (in /usr/lib64/libgobject-2.0.so.0.6200.5) ==5526== by 0x54C6710: g_object_new (in /usr/lib64/libgobject-2.0.so.0.6200.5) ==5526== by 0x4B3DEB8: gtk_settings_get_for_display (in /usr/lib64/libgtk-3.so.0.2404.9) ==5526== by 0x4ACC737: display_opened_cb (in /usr/lib64/libgtk-3.so.0.2404.9) ==5526== ==5526== ==5526== HEAP SUMMARY: ==5526== in use at exit: 2,419,006 bytes in 27,441 blocks ==5526== total heap usage: 297,247 allocs, 269,806 frees, 40,037,735 bytes allocated ==5526== ==5526== LEAK SUMMARY: ==5526== definitely lost: 5,960 bytes in 14 blocks ==5526== indirectly lost: 26,324 bytes in 1,102 blocks ==5526== possibly lost: 5,428 bytes in 55 blocks ==5526== still reachable: 2,282,798 bytes in 25,484 blocks ==5526== of which reachable via heuristic: ==5526== length64 : 5,816 bytes in 95 blocks ==5526== newarray : 2,128 bytes in 53 blocks ==5526== suppressed: 0 bytes in 0 blocks ==5526== Rerun with --leak-check=full to see details of leaked memory ==5526== ==5526== For lists of detected and suppressed errors, rerun with: -s ==5526== ERROR SUMMARY: 78 errors from 1 contexts (suppressed: 0 from 0)
Well, when for the C code such errors are already reported, then it makes no real sense to test the Nim bindings with Valgrind. Any ideas? Will GTK4 work better?
Well, you may say that the gtk libs may allocate some internal buffers, and next start of the executable will work fine. But I tried starting multiple time, and result is not really better.
I do not know much about valgrind, maybe I am doing something wrong.