Messages

1

General discussions / Re: Leaks when linking

« on: April 28, 2020, 10:02:44 am »

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

2

General discussions / Re: Leaks when linking

« on: April 27, 2020, 10:57:22 am »

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 ^^'

3

General discussions / Re: Leaks when linking

« on: April 27, 2020, 09:38:56 am »

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...

4

General discussions / Re: Leaks when linking

« on: April 26, 2020, 09:17:20 pm »

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

5

General discussions / Re: Leaks when linking

« on: April 26, 2020, 03:19:13 pm »

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 ?

6

General discussions / Leaks when linking

« on: April 25, 2020, 05:02:01 pm »

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.