Gdk_display_get_default

Development
1

I used gdk_display_get_default to add CSS to my application. To simplify, just think of a bare bone hello world app, using GtkApplication and GtkApplicationWindow, that make the background color of the window dark grey.

What confused me, was the the ref count for the display reached 5 after presenting the window, and remained 5 when the app was going to close. I checked the ref count on the last line of execution, and it was still 5?

Why is that? Do I not have to clean this up? There must be a bunch of stuff still in memory somewhere with such a ref count.

Can i close the display? Will that free this up?

Is this a bug?

2

Various objects inside GTK can acquire a reference on the default display, which is guaranteed by the API contract to be available after GTK has been initialised and for the duration of the process.

You don’t have to clean up the default display, and yes: there will likely be things still in memory once the process terminates; it’s a lot cheaper, and more efficient, to let the operating system clean up the memory when the process terminates, rather than you doing so manually.

Not really, and no.

GTK, and various of its dependencies, make one-off allocations at startup; those are not memory leaks, and do not constitute a bug.

If you want to be sure that your code is not leaking, you should use tools like ASan and Valgrind.

3

Valgrind always tells me that I have no leaks, but after my application has been running for 3 months, then the users can notice that is is running out of memory. It is a system that is running 24 hours every day.

How can i used the ASan with GTK4? I find ASan confusing. For my sample app, while Valgrind give no memory leaks, ASan gives me this:

**==24060==ERROR: LeakSanitizer: detected memory leaks** 

**Direct leak of 256 byte(s) in 1 object(s) allocated from:** 
    #0 0x7fcff02f4c57 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 
    #1 0x7fcfeead49e1  (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x259e1) (BuildId: ffede8685d668e17caf92e8617256
83778418f9a) 

**Direct leak of 240 byte(s) in 6 object(s) allocated from:** 
    #0 0x7fcff02f4c57 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 
    #1 0x7fcfef164701 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x65701) (BuildId: f0bf78d9d8d4021e2d8e
de0c42e771aca06ec7f1) 

**Indirect leak of 6144 byte(s) in 6 object(s) allocated from:** 
    #0 0x7fcff02f3b58 in realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:85 
    #1 0x7fcfef1647a1 in g_realloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x657a1) (BuildId: f0bf78d9d8d4021e2d8
ede0c42e771aca06ec7f1) 

**Indirect leak of 233 byte(s) in 124 object(s) allocated from:** 
    #0 0x7fcff02f4c57 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 
    #1 0x7fcfef164701 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x65701) (BuildId: f0bf78d9d8d4021e2d8e
de0c42e771aca06ec7f1) 

**Indirect leak of 64 byte(s) in 2 object(s) allocated from:** 
    #0 0x7fcff02f4610 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 
    #1 0x7fcfeead525c  (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x2625c) (BuildId: ffede8685d668e17caf92e8617256
83778418f9a) 

SUMMARY: AddressSanitizer: 6937 byte(s) leaked in 139 allocation(s).
4

Those look like one-off allocations.

You’ll have to run it for a while, if the leak appears on a long enough time frame.

5

What do you mean by: run it for a long time? You mean Valgrind? I dont get it?

So it seems like Valgrind does not report the one-off allocations, which are not really memory leaks, but the ASan does report them (false positives) as memory leaks. This is my Valgrind output for the same sample app:

==24285== Memcheck, a memory error detector
==24285== Copyright (C) 2002-2024, and GNU GPL’d, by Julian Seward et al.
==24285== Using Valgrind-3.24.0 and LibVEX; rerun with -h for copyright info
==24285== Command: ./test
==24285==
==24285==
==24285== HEAP SUMMARY:
==24285== in use at exit: 2,654 bytes in 83 blocks
==24285== total heap usage: 83 allocs, 0 frees, 2,654 bytes allocated
==24285==
==24285== LEAK SUMMARY:
==24285== definitely lost: 0 bytes in 0 blocks
==24285== indirectly lost: 0 bytes in 0 blocks
==24285== possibly lost: 0 bytes in 0 blocks
==24285== still reachable: 2,654 bytes in 83 blocks
==24285== suppressed: 0 bytes in 0 blocks
==24285== Rerun with --leak-check=full to see details of leaked memory
==24285==
==24285== For lists of detected and suppressed errors, rerun with: -s
==24285== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I have no clue now, as to how i can find the leaks.

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.