Search code examples
c++memory-leakssfmladdress-sanitizer

Stack allocated sf::Texture causes "LeakSanitizer: detected memory leaks"

Creating a texture on the stack is causing a memory leak according to LeakSanitizer. Is this a false positive?

I'm using sfml version 2.5.1 on a macOS Mojave.

main.cpp

#include <SFML/Graphics.hpp>

int main(int, char const**) {
    sf::Texture texture;
}

compilation

clang++ -Wall -Weffc++ -Werror -pedantic -g -fsanitize=address -fno-omit-frame-pointer -lstdc++ -lsfml-graphics main.cpp

run

➜  test_sfml_texture ASAN_OPTIONS=detect_leaks=1 ./a.out

=================================================================
==48054==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 120 byte(s) in 1 object(s) allocated from:
    #0 0x1005b1287 in wrap_calloc (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x61287)
    #1 0x7fff7690e4eb in class_createInstance (libobjc.A.dylib:x86_64h+0x64eb)
    #2 0x7fff7809cef3 in _os_object_alloc_realized (libdispatch.dylib:x86_64+0x2ef3)
    #3 0x7fff780adb37 in dispatch_source_create (libdispatch.dylib:x86_64+0x13b37)
    #4 0x7fff780b81eb in _dispatch_kq_poll (libdispatch.dylib:x86_64+0x1e1eb)
    #5 0x7fff780b7d3a in _dispatch_kq_drain (libdispatch.dylib:x86_64+0x1dd3a)
    #6 0x7fff780b72b1 in _dispatch_kq_unote_update (libdispatch.dylib:x86_64+0x1d2b1)
    #7 0x7fff780ae720 in _dispatch_source_install (libdispatch.dylib:x86_64+0x14720)
    #8 0x7fff780ae67c in _dispatch_source_activate (libdispatch.dylib:x86_64+0x1467c)
    #9 0x7fff780a2b9a in _dispatch_lane_resume_activate (libdispatch.dylib:x86_64+0x8b9a)
    #10 0x7fff713176b8 in (anonymous namespace)::RunElsewhere::instance() (SkyLight:x86_64+0x1d6b8)
    #11 0x7fff71456f59 in __SLSInitialize_block_invoke (SkyLight:x86_64+0x15cf59)
    #12 0x7fff7809d63c in _dispatch_client_callout (libdispatch.dylib:x86_64+0x363c)
    #13 0x7fff7809ed4b in _dispatch_once_callout (libdispatch.dylib:x86_64+0x4d4b)
    #14 0x7fff7130802e in CGS_CHECK_INIT (SkyLight:x86_64+0xe02e)
    #15 0x7fff714ca6a0 in SLSMainDisplayID (SkyLight:x86_64+0x1d06a0)
    #16 0x101288126 in sf::priv::VideoModeImpl::getDesktopMode() (libsfml-window.2.5.dylib:x86_64+0x1a126)
    #17 0x101282409 in sf::priv::SFContext::SFContext(sf::priv::SFContext*) (libsfml-window.2.5.dylib:x86_64+0x14409)
    #18 0x101273932 in sf::priv::GlContext::initResource() (libsfml-window.2.5.dylib:x86_64+0x5932)
    #19 0x10050e482 in sf::Texture::Texture() (libsfml-graphics.2.5.dylib:x86_64+0x3e482)
    #20 0x1004cce70 in main main.cpp:4
    #21 0x7fff780ea3d4 in start (libdyld.dylib:x86_64+0x163d4)

system

➜  test_sfml_texture  which clang
/usr/local/opt/llvm@8/bin/clang
➜  test_sfml_texture clang++ --version
clang version 8.0.1 (tags/RELEASE_801/final)
Target: x86_64-apple-darwin18.6.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm@8/bin
Solution

  • This is better reported on the official forum, as mostly the maintainers will be able to tell you, whether it's an actual leak or just a false-positive.

    Looking at the source, I don't really see how anything is leaked and it seems more like macOS itself would leak something. Only thing I could vaguely think of is that the returned value from CGMainDisplayID also needs to be releases again.

    Note: If you make use of the new C++ standards, especially smart pointers and avoid doing manual memory management, there's often little need to track memory leaks regularly, as they tend to not happen anymore (i.e. memory automatically freed once the smart pointer runs out of scope).