Leaks when linking

[Ezarkei]

Hello !

-almost- 3 years after my first sfml program, I still can't get around some weird, weird weiiiiiiird leak.
If I do an empty main, as simple as

Code: [Select]

int main(){return 0;}and compile with

Code: [Select]

g++ [file].cpp -lsfml-graphicsand run

Code: [Select]

valgrind ./a.outI got leaks reports.

leaks:

Code: [Select]

still reachable: 18,612 bytes in 6 blocks
some details with --leak-check=full and --show-leak-kinds=all:

Code: [Select]

==5515== 4 bytes in 1 blocks are still reachable in loss record 1 of 6
==5515==    at 0x483977F: malloc (vg_replace_malloc.c:309)
==5515==    by 0x53FE684: ??? (in /usr/lib/libglib-2.0.so.0.6400.2)
==5515==    by 0x53FE75B: g_private_get (in /usr/lib/libglib-2.0.so.0.6400.2)
==5515==    by 0x54281FD: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6400.2)
==5515==    by 0x5460E0E: g_hash_table_new_full (in /usr/lib/libglib-2.0.so.0.6400.2)
==5515==    by 0x543EF5B: ??? (in /usr/lib/libglib-2.0.so.0.6400.2)
==5515==    by 0x4011099: call_init.part.0 (in /usr/lib/ld-2.31.so)
==5515==    by 0x40111A0: _dl_init (in /usr/lib/ld-2.31.so)
==5515==    by 0x4002139: ??? (in /usr/lib/ld-2.31.so)
If anybody knows anything about this, I would like to know why this is happening, and if possible, how to fix it !

I tried this on 2 different hardwares with different graphics drivers, under fedora, manjaro and arch linux, and I still have the same issue.

[Laurent]

Most likely memory allocated by global SFML resources, before main() enters. I don't know about valgrind, but some tools can only track memory leaks correctly inside main(). This report doesn't mean that the memory leaks, you can ignore it.

[Ezarkei]

Ok, thank you !

Any tips or things about that report ?

Code: [Select]

==2188== Invalid read of size 8
==2188==    at 0x401EF18: strncmp (in /usr/lib/ld-2.31.so)
==2188==    by 0x400706D: is_dst (in /usr/lib/ld-2.31.so)
==2188==    by 0x4009796: _dl_dst_count (in /usr/lib/ld-2.31.so)
==2188==    by 0x4009985: expand_dynamic_string_token (in /usr/lib/ld-2.31.so)
==2188==    by 0x4009AE1: fillin_rpath (in /usr/lib/ld-2.31.so)
==2188==    by 0x4009DF3: decompose_rpath.isra.0 (in /usr/lib/ld-2.31.so)
==2188==    by 0x400A708: _dl_map_object (in /usr/lib/ld-2.31.so)
==2188==    by 0x400EE84: openaux (in /usr/lib/ld-2.31.so)
==2188==    by 0x4DBA8A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==2188==    by 0x400F202: _dl_map_object_deps (in /usr/lib/ld-2.31.so)
==2188==    by 0x4014E2E: dl_open_worker (in /usr/lib/ld-2.31.so)
==2188==    by 0x4DBA8A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==2188==  Address 0x5ee0cc9 is 9 bytes inside a block of size 15 alloc'd
==2188==    at 0x483977F: malloc (vg_replace_malloc.c:309)
==2188==    by 0x401DA6E: strdup (in /usr/lib/ld-2.31.so)
==2188==    by 0x4009D84: decompose_rpath.isra.0 (in /usr/lib/ld-2.31.so)
==2188==    by 0x400A708: _dl_map_object (in /usr/lib/ld-2.31.so)
==2188==    by 0x400EE84: openaux (in /usr/lib/ld-2.31.so)
==2188==    by 0x4DBA8A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==2188==    by 0x400F202: _dl_map_object_deps (in /usr/lib/ld-2.31.so)
==2188==    by 0x4014E2E: dl_open_worker (in /usr/lib/ld-2.31.so)
==2188==    by 0x4DBA8A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==2188==    by 0x401496D: _dl_open (in /usr/lib/ld-2.31.so)
==2188==    by 0x59CE34B: ??? (in /usr/lib/libdl-2.31.so)
==2188==    by 0x4DBA8A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==2188==
==2188== Invalid read of size 8
==2188==    at 0x401EF18: strncmp (in /usr/lib/ld-2.31.so)
==2188==    by 0x400706D: is_dst (in /usr/lib/ld-2.31.so)
==2188==    by 0x400984E: _dl_dst_substitute (in /usr/lib/ld-2.31.so)
==2188==    by 0x4009AE1: fillin_rpath (in /usr/lib/ld-2.31.so)
==2188==    by 0x4009DF3: decompose_rpath.isra.0 (in /usr/lib/ld-2.31.so)
==2188==    by 0x400A708: _dl_map_object (in /usr/lib/ld-2.31.so)
==2188==    by 0x400EE84: openaux (in /usr/lib/ld-2.31.so)
==2188==    by 0x4DBA8A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==2188==    by 0x400F202: _dl_map_object_deps (in /usr/lib/ld-2.31.so)
==2188==    by 0x4014E2E: dl_open_worker (in /usr/lib/ld-2.31.so)
==2188==    by 0x4DBA8A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==2188==    by 0x401496D: _dl_open (in /usr/lib/ld-2.31.so)
==2188==  Address 0x5ee0cc9 is 9 bytes inside a block of size 15 alloc'd
==2188==    at 0x483977F: malloc (vg_replace_malloc.c:309)
==2188==    by 0x401DA6E: strdup (in /usr/lib/ld-2.31.so)
==2188==    by 0x4009D84: decompose_rpath.isra.0 (in /usr/lib/ld-2.31.so)
==2188==    by 0x400A708: _dl_map_object (in /usr/lib/ld-2.31.so)
==2188==    by 0x400EE84: openaux (in /usr/lib/ld-2.31.so)
==2188==    by 0x4DBA8A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==2188==    by 0x400F202: _dl_map_object_deps (in /usr/lib/ld-2.31.so)
==2188==    by 0x4014E2E: dl_open_worker (in /usr/lib/ld-2.31.so)
==2188==    by 0x4DBA8A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==2188==    by 0x401496D: _dl_open (in /usr/lib/ld-2.31.so)
==2188==    by 0x59CE34B: ??? (in /usr/lib/libdl-2.31.so)
==2188==    by 0x4DBA8A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==2188==
==2188== Conditional jump or move depends on uninitialised value(s)
==2188==    at 0x12097F5E: pa_shm_cleanup (in /usr/lib/pulseaudio/libpulsecommon-13.0.so)
==2188==    by 0x1209989F: pa_shm_create_rw (in /usr/lib/pulseaudio/libpulsecommon-13.0.so)
==2188==    by 0x120A4B96: pa_mempool_new (in /usr/lib/pulseaudio/libpulsecommon-13.0.so)
==2188==    by 0x120544FA: pa_context_new_with_proplist (in /usr/lib/libpulse.so.0.21.1)
==2188==    by 0x518E0EA: ??? (in /usr/lib/libopenal.so.1.20.1)
==2188==    by 0x51911AE: ??? (in /usr/lib/libopenal.so.1.20.1)
==2188==    by 0x515082A: ??? (in /usr/lib/libopenal.so.1.20.1)
==2188==    by 0x599292E: __pthread_once_slow (in /usr/lib/libpthread-2.31.so)
==2188==    by 0x5152F59: alcOpenDevice (in /usr/lib/libopenal.so.1.20.1)
==2188==    by 0x4915D9E: ??? (in /usr/lib/libsfml-audio.so.2.5.1)
==2188==    by 0x4915CAB: sf::AlResource::AlResource() (in /usr/lib/libsfml-audio.so.2.5.1)
==2188==    by 0x491A1AF: sf::SoundSource::SoundSource() (in /usr/lib/libsfml-audio.so.2.5.1)
==2188==
==2188==
==2188== HEAP SUMMARY:
==2188==     in use at exit: 248,975 bytes in 2,402 blocks
==2188==   total heap usage: 32,346 allocs, 29,944 frees, 21,973,071 bytes allocated
==2188==
==2188== LEAK SUMMARY:
==2188==    definitely lost: 8 bytes in 2 blocks
==2188==    indirectly lost: 0 bytes in 0 blocks
==2188==      possibly lost: 0 bytes in 0 blocks
==2188==    still reachable: 248,967 bytes in 2,400 blocks
==2188==         suppressed: 0 bytes in 0 blocks
==2188== Rerun with --leak-check=full to see details of leaked memory
==2188==
==2188== Use --track-origins=yes to see where uninitialised values come from
==2188== For lists of detected and suppressed errors, rerun with: -s
==2188== ERROR SUMMARY: 4 errors from 3 contexts (suppressed: 0 from 0)

It happens when I compile and run that:

#include <SFML/Graphics.hpp>
#include <SFML/Audio.hpp>

int main() {
    sf::RenderWindow window(sf::VideoMode(800, 600), "courge");
    sf::Texture texture;
    if (!texture.loadFromFile("arial.jpg"))
        abort();
    sf::Sprite sprite(texture);
    sf::Font font;
    if (!font.loadFromFile("arial.ttf"))
        abort();
    sf::Text text("arial", font, 50);
    sf::Music music;
    if (!music.openFromFile("arial.ogg"))
        abort();
    music.play();
    while (window.isOpen()) {
        sf::Event event;
        while (window.pollEvent(event)) {
            if ((event.type == sf::Event::KeyPressed && sf::Keyboard::Escape == event.key.code) || event.type == sf:\
:Event::Closed)
                window.close();
        }
        window.clear(sf::Color::Black);
        window.draw(sprite);
        window.draw(text);
        window.display();
    }
    return 0;
}
 

I know the audio part is not an issue from the sfml but from libopenal or pulseaudio, but what about the other errors and leaks ?

[Laurent]

std::abort() triggers abnormal termination. Destructors of static and global variables are not called, and thus the corresponding memory is not freed.

[Ezarkei]

That's not the point, It's not called it's a dummy code

[Laurent]

I'm not supposed to know what's called and what's not, and what code path resulted in this memory report
No need to put this kind of trick in a minimal code, "return -1" would have done the same job and be much less confusing.

I have no idea what these "leaks" refer to, but I wouldn't waste too much time on them anyway. Leaks that are worth investigating are those that occur frequently (and can lead to high memory consumption), those leaks are global ones and won't occur more than once in your app lifetime.

[Ezarkei]

Yeah, sorry but you could have guessed because of the valgrind output : an abort signal is shown by valgrind when it occurs.
Anyway, those leaks are slightly increasing over time, that's the issue. I haven't measured the size of leaks / second, but I will do it after work.
And what about those invalid reads ? It ends up in strncmp but I don't know why it comes from the dynamic handling of sfml...

[Laurent]

Yeah, sorry but you could have guessed because of the valgrind output : an abort signal is shown by valgrind when it occurs.

I never use valgrind

Anyway, those leaks are slightly increasing over time, that's the issue.

Ok! You should have started by saying it.

I have no idea about these leaks, so you can investigate if you want. However be aware that it may not come from SFML directly, but rather from the drivers or low-level libraries that it uses.

You can start by removing parts of your code that don't remove the leak (I'm pretty sure you don't need a mix of text, sprite, and music to trigger it), and then provide a detailed report (amount of memory leaked per second or minute, what exact call triggers it, etc.).

[Ezarkei]

Ok, thank you ! I will do that as soon as I got free time :')
Sure, it's related to the texture creation and the update of the sprite from what I remember, not the whole example.
Any tips on how to track leaks on windows ? I would like to check if it's happening there too because every linux os and drivers I tried had those.
I have no experience debugging / tracking on windows because I use linux to code and windows to check if my app is cross platform ^^'

[Laurent]

On Windows I know that Visual Studio has embedded stuff to track memory leaks. I don't know what else is available, sorry. That's not the kind of tools I know very well.

[eXpl0it3r]

Note that you'll be comparing fundamentally different implementation code, so the results between OS are not really/fully comparable.

Personally, I'd recommend to stick to "modern" C++ constructs like unique_ptr/shared_ptr/other RAII wrappers if necessary and never do manual memory management, that way you can pretty much guarantee leak free code and don't have to spend a lot of time, trying to hunt down leaks in third-party code.
Of course we're happy if you want to help us fix any leaks, but if you want to write some game or application, it might be more productive to invest your time on that, instead of leak hunting.

[Ezarkei]

Yeah, but RAII code doesn't fade away leaks increasing with time, uh
Of course I know how to write C++ code, it's just... Annoying to see an increasing amount of leaks. But nobody seem to care about that, or the invalid reads.
Anyway thanks you for your time ! I will try to fix those or maybe switch back to pure opengl