Show Posts
1
Graphics / sf::Texture memory leak?
« on: May 08, 2020, 10:40:30 am »
Hello there!
Im pretty new to using SFML, but in one of my projects i made a function into a functor and basically everything fell apart (new/delete not working, sf classes having problems with memory management, etc), so i went ahead and did a check up with valgrind.
What i found was that there seems to be a memory leak caused by sf::Texture::update, even in this simple code:
valgrind output:
And im also pretty new to valgrind, so "invalid read of size 8", i dont know what that means...
BUT what i found interesting was that even a code as simple as:
causes memory leak by itself, and this "invalid read size of 8":
-------------------------------------------------------------------------------------------------------------------------
I tried searching for anything related to this, and it seems i might be the only one who's experiencing a memory leak caused by sf::Texture so Im not sure this is a real bug and not just caused by something i dont know about but i should.
So firstly i'd like to ask someone to please try to replicate this, and check for me if this really is a problem, or if its a problem on my end, and secondly if this is a problem on my end, any idea what might cause it, or how to fix it?
Thanks,
Coldus
-------------------------------------------------------------------------------------------------------------------------------------------------
EDIT: Some notes: In my project the new/delete problems were probably caused by my own memory management/doing, and after i fixed that it didnt crash, nevertheless since i saw that sf::Texture appeared to be leaking i wanted to fix that too.
Now i found this: https://en.sfml-dev.org/forums/index.php?topic=17825.0
where zsbzsb says:
Im pretty new to using SFML, but in one of my projects i made a function into a functor and basically everything fell apart (new/delete not working, sf classes having problems with memory management, etc), so i went ahead and did a check up with valgrind.
What i found was that there seems to be a memory leak caused by sf::Texture::update, even in this simple code:
Quote
sf::Texture text;
text.loadFromFile("textures/bloody_wall_v2.png");
sf::Texture newS;
newS.loadFromFile("textures/bloody_wall.png");
text.update(newS,0,0);
valgrind output:
Quote
==3454== Memcheck, a memory error detector
==3454== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3454== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==3454== Command: ./array2d
==3454==
==3454== Invalid read of size 8
==3454== at 0x401EF18: strncmp (in /usr/lib/ld-2.31.so)
==3454== by 0x400706D: is_dst (in /usr/lib/ld-2.31.so)
==3454== by 0x4009796: _dl_dst_count (in /usr/lib/ld-2.31.so)
==3454== by 0x4009985: expand_dynamic_string_token (in /usr/lib/ld-2.31.so)
==3454== by 0x4009AE1: fillin_rpath (in /usr/lib/ld-2.31.so)
==3454== by 0x4009DF3: decompose_rpath.isra.0 (in /usr/lib/ld-2.31.so)
==3454== by 0x400A708: _dl_map_object (in /usr/lib/ld-2.31.so)
==3454== by 0x400EE84: openaux (in /usr/lib/ld-2.31.so)
==3454== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3454== by 0x400F202: _dl_map_object_deps (in /usr/lib/ld-2.31.so)
==3454== by 0x4014E2E: dl_open_worker (in /usr/lib/ld-2.31.so)
==3454== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3454== Address 0x5f677a9 is 9 bytes inside a block of size 15 alloc'd
==3454== at 0x483977F: malloc (vg_replace_malloc.c:309)
==3454== by 0x401DA6E: strdup (in /usr/lib/ld-2.31.so)
==3454== by 0x4009D84: decompose_rpath.isra.0 (in /usr/lib/ld-2.31.so)
==3454== by 0x400A708: _dl_map_object (in /usr/lib/ld-2.31.so)
==3454== by 0x400EE84: openaux (in /usr/lib/ld-2.31.so)
==3454== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3454== by 0x400F202: _dl_map_object_deps (in /usr/lib/ld-2.31.so)
==3454== by 0x4014E2E: dl_open_worker (in /usr/lib/ld-2.31.so)
==3454== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3454== by 0x401496D: _dl_open (in /usr/lib/ld-2.31.so)
==3454== by 0x5C0134B:(in /usr/lib/libdl-2.31.so)
==3454== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3454==
==3454== Invalid read of size 8
==3454== at 0x401EF18: strncmp (in /usr/lib/ld-2.31.so)
==3454== by 0x400706D: is_dst (in /usr/lib/ld-2.31.so)
==3454== by 0x400984E: _dl_dst_substitute (in /usr/lib/ld-2.31.so)
==3454== by 0x4009AE1: fillin_rpath (in /usr/lib/ld-2.31.so)
==3454== by 0x4009DF3: decompose_rpath.isra.0 (in /usr/lib/ld-2.31.so)
==3454== by 0x400A708: _dl_map_object (in /usr/lib/ld-2.31.so)
==3454== by 0x400EE84: openaux (in /usr/lib/ld-2.31.so)
==3454== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3454== by 0x400F202: _dl_map_object_deps (in /usr/lib/ld-2.31.so)
==3454== by 0x4014E2E: dl_open_worker (in /usr/lib/ld-2.31.so)
==3454== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3454== by 0x401496D: _dl_open (in /usr/lib/ld-2.31.so)
==3454== Address 0x5f677a9 is 9 bytes inside a block of size 15 alloc'd
==3454== at 0x483977F: malloc (vg_replace_malloc.c:309)
==3454== by 0x401DA6E: strdup (in /usr/lib/ld-2.31.so)
==3454== by 0x4009D84: decompose_rpath.isra.0 (in /usr/lib/ld-2.31.so)
==3454== by 0x400A708: _dl_map_object (in /usr/lib/ld-2.31.so)
==3454== by 0x400EE84: openaux (in /usr/lib/ld-2.31.so)
==3454== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3454== by 0x400F202: _dl_map_object_deps (in /usr/lib/ld-2.31.so)
==3454== by 0x4014E2E: dl_open_worker (in /usr/lib/ld-2.31.so)
==3454== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3454== by 0x401496D: _dl_open (in /usr/lib/ld-2.31.so)
==3454== by 0x5C0134B:
==3454== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3454==
==3454==
==3454== HEAP SUMMARY:
==3454== in use at exit: 149,359 bytes in 1,740 blocks
==3454== total heap usage: 15,904 allocs, 14,164 frees, 5,375,171 bytes allocated
==3454==
==3454== 64 bytes in 1 blocks are definitely lost in loss record 1,374 of 1,419
==3454== at 0x483BB65: calloc (vg_replace_malloc.c:762)
==3454== by 0x70FB65C:
==3454== by 0x70FF091:
==3454== by 0x6690645:
==3454== by 0x6690824:
==3454== by 0x6683D5C:
==3454== by 0x6BA7B45:
==3454== by 0x6271808:
==3454== by 0x625D02C:
==3454== by 0x5A76C22:
==3454== by 0x5A7D1EE:
==3454== by 0x5A7DABC:
==3454==
==3454== 128 bytes in 1 blocks are definitely lost in loss record 1,398 of 1,419
==3454== at 0x483BB65: calloc (vg_replace_malloc.c:762)
==3454== by 0x70FB65C:
==3454== by 0x70FF091:
==3454== by 0x66A39A8:
==3454== by 0x66A42ED:
==3454== by 0x6769F99:
==3454== by 0x676A39B:
==3454== by 0x676A689:
==3454== by 0x48C0298: sf::Texture::update(sf::Texture const&, unsigned int, unsigned int) (in /usr/lib/libsfml-graphics.so.2.5.1)
==3454== by 0x109312: main (main.cpp:80)
==3454==
==3454== 128 bytes in 1 blocks are definitely lost in loss record 1,399 of 1,419
==3454== at 0x483BB65: calloc (vg_replace_malloc.c:762)
==3454== by 0x70FB65C:
==3454== by 0x70FF091:
==3454== by 0x66A39A8:
==3454== by 0x66A42ED:
==3454== by 0x6769F99:
==3454== by 0x676A39B:
==3454== by 0x676A689:
==3454== by 0x48C02C7: sf::Texture::update(sf::Texture const&, unsigned int, unsigned int) (in /usr/lib/libsfml-graphics.so.2.5.1)
==3454== by 0x109312: main (main.cpp:80)
==3454==
==3454== LEAK SUMMARY:
==3454== definitely lost: 320 bytes in 3 blocks
==3454== indirectly lost: 0 bytes in 0 blocks
==3454== possibly lost: 0 bytes in 0 blocks
==3454== still reachable: 149,039 bytes in 1,737 blocks
==3454== suppressed: 0 bytes in 0 blocks
==3454== Reachable blocks (those to which a pointer was found) are not shown.
==3454== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==3454==
==3454== For lists of detected and suppressed errors, rerun with: -s
==3454== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0)
And im also pretty new to valgrind, so "invalid read of size 8", i dont know what that means...
BUT what i found interesting was that even a code as simple as:
Quote
sf::Texture text;
causes memory leak by itself, and this "invalid read size of 8":
Quote
==3636== Memcheck, a memory error detector
==3636== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3636== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==3636== Command: ./array2d
==3636==
==3636== Invalid read of size 8
==3636== at 0x401EF18: strncmp (in /usr/lib/ld-2.31.so)
==3636== by 0x400706D: is_dst (in /usr/lib/ld-2.31.so)
==3636== by 0x4009796: _dl_dst_count (in /usr/lib/ld-2.31.so)
==3636== by 0x4009985: expand_dynamic_string_token (in /usr/lib/ld-2.31.so)
==3636== by 0x4009AE1: fillin_rpath (in /usr/lib/ld-2.31.so)
==3636== by 0x4009DF3: decompose_rpath.isra.0 (in /usr/lib/ld-2.31.so)
==3636== by 0x400A708: _dl_map_object (in /usr/lib/ld-2.31.so)
==3636== by 0x400EE84: openaux (in /usr/lib/ld-2.31.so)
==3636== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3636== by 0x400F202: _dl_map_object_deps (in /usr/lib/ld-2.31.so)
==3636== by 0x4014E2E: dl_open_worker (in /usr/lib/ld-2.31.so)
==3636== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3636== Address 0x5f677a9 is 9 bytes inside a block of size 15 alloc'd
==3636== at 0x483977F: malloc (vg_replace_malloc.c:309)
==3636== by 0x401DA6E: strdup (in /usr/lib/ld-2.31.so)
==3636== by 0x4009D84: decompose_rpath.isra.0 (in /usr/lib/ld-2.31.so)
==3636== by 0x400A708: _dl_map_object (in /usr/lib/ld-2.31.so)
==3636== by 0x400EE84: openaux (in /usr/lib/ld-2.31.so)
==3636== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3636== by 0x400F202: _dl_map_object_deps (in /usr/lib/ld-2.31.so)
==3636== by 0x4014E2E: dl_open_worker (in /usr/lib/ld-2.31.so)
==3636== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3636== by 0x401496D: _dl_open (in /usr/lib/ld-2.31.so)
==3636== by 0x5C0134B:
==3636== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3636==
==3636== Invalid read of size 8
==3636== at 0x401EF18: strncmp (in /usr/lib/ld-2.31.so)
==3636== by 0x400706D: is_dst (in /usr/lib/ld-2.31.so)
==3636== by 0x400984E: _dl_dst_substitute (in /usr/lib/ld-2.31.so)
==3636== by 0x4009AE1: fillin_rpath (in /usr/lib/ld-2.31.so)
==3636== by 0x4009DF3: decompose_rpath.isra.0 (in /usr/lib/ld-2.31.so)
==3636== by 0x400A708: _dl_map_object (in /usr/lib/ld-2.31.so)
==3636== by 0x400EE84: openaux (in /usr/lib/ld-2.31.so)
==3636== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3636== by 0x400F202: _dl_map_object_deps (in /usr/lib/ld-2.31.so)
==3636== by 0x4014E2E: dl_open_worker (in /usr/lib/ld-2.31.so)
==3636== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3636== by 0x401496D: _dl_open (in /usr/lib/ld-2.31.so)
==3636== Address 0x5f677a9 is 9 bytes inside a block of size 15 alloc'd
==3636== at 0x483977F: malloc (vg_replace_malloc.c:309)
==3636== by 0x401DA6E: strdup (in /usr/lib/ld-2.31.so)
==3636== by 0x4009D84: decompose_rpath.isra.0 (in /usr/lib/ld-2.31.so)
==3636== by 0x400A708: _dl_map_object (in /usr/lib/ld-2.31.so)
==3636== by 0x400EE84: openaux (in /usr/lib/ld-2.31.so)
==3636== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3636== by 0x400F202: _dl_map_object_deps (in /usr/lib/ld-2.31.so)
==3636== by 0x4014E2E: dl_open_worker (in /usr/lib/ld-2.31.so)
==3636== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3636== by 0x401496D: _dl_open (in /usr/lib/ld-2.31.so)
==3636== by 0x5C0134B:
==3636== by 0x4DB78A7: _dl_catch_exception (in /usr/lib/libc-2.31.so)
==3636==
==3636==
==3636== HEAP SUMMARY:
==3636== in use at exit: 147,403 bytes in 1,737 blocks
==3636== total heap usage: 11,870 allocs, 10,133 frees, 4,507,877 bytes allocated
==3636==
==3636== 64 bytes in 1 blocks are definitely lost in loss record 1,374 of 1,416
==3636== at 0x483BB65: calloc (vg_replace_malloc.c:762)
==3636== by 0x70FB65C:
==3636== by 0x70FF091:
==3636== by 0x6690645:
==3636== by 0x6690824:
==3636== by 0x6683D5C:
==3636== by 0x6BA7B45:
==3636== by 0x6271808:
==3636== by 0x625D02C:
==3636== by 0x5A76C22:
==3636== by 0x5A7D1EE:
==3636== by 0x5A7DABC:
==3636==
==3636== LEAK SUMMARY:
==3636== definitely lost: 64 bytes in 1 blocks
==3636== indirectly lost: 0 bytes in 0 blocks
==3636== possibly lost: 0 bytes in 0 blocks
==3636== still reachable: 147,339 bytes in 1,736 blocks
==3636== suppressed: 0 bytes in 0 blocks
==3636== Reachable blocks (those to which a pointer was found) are not shown.
==3636== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==3636==
==3636== For lists of detected and suppressed errors, rerun with: -s
==3636== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
-------------------------------------------------------------------------------------------------------------------------
I tried searching for anything related to this, and it seems i might be the only one who's experiencing a memory leak caused by sf::Texture so Im not sure this is a real bug and not just caused by something i dont know about but i should.
So firstly i'd like to ask someone to please try to replicate this, and check for me if this really is a problem, or if its a problem on my end, and secondly if this is a problem on my end, any idea what might cause it, or how to fix it?
Thanks,
Coldus
-------------------------------------------------------------------------------------------------------------------------------------------------
EDIT: Some notes: In my project the new/delete problems were probably caused by my own memory management/doing, and after i fixed that it didnt crash, nevertheless since i saw that sf::Texture appeared to be leaking i wanted to fix that too.
Now i found this: https://en.sfml-dev.org/forums/index.php?topic=17825.0
where zsbzsb says:
Quote
I'm not sure what the point of posting valgrind output is... it is known that valgrind 'detects' memory leaks within SFML.Now if thats the case then this is a false positive, and there is nothing to be worried about.