Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Memory leak in SFML 2.5.1 hello world program in Ubuntu 20.04  (Read 2016 times)

0 Members and 1 Guest are viewing this topic.

metal_in_my_veins

  • Newbie
  • *
  • Posts: 10
    • View Profile
    • Email
Memory leak in SFML 2.5.1 hello world program in Ubuntu 20.04
« on: January 01, 2022, 08:59:49 pm »
So I was testing the memory usage of SFML hello world program. This is the program:
#include <SFML/Graphics/RenderWindow.hpp>
#include <SFML/Window/Event.hpp>
#include <SFML/Window/Keyboard.hpp>
#include <SFML/Window/VideoMode.hpp>
#include <SFML/Window/WindowStyle.hpp>

int main()
{
  sf::RenderWindow window{sf::VideoMode{1366, 768}, "Test", sf::Style::Fullscreen};

  while (window.isOpen())
  {
    sf::Event event;
    while (window.pollEvent(event))
    {
      if (event.type == sf::Event::Closed){ window.close(); }
      if (sf::Keyboard::isKeyPressed(sf::Keyboard::Escape)){ window.close(); }
    }

    window.clear();
    window.display();
  }
}
 

I did this to compile it:
clang++ test.cxx -o vimbin -O2 -std=c++20 -Wall -ggdb3 -lsfml-graphics -lsfml-window -lsfml-system

Then I did this to check for any memory leaks using valgrind:
valgrind --leak-check=full ./vimbin

This is the portion of valgrind output after I ran the binary under valgrind for 10 seconds:
==10183== HEAP SUMMARY:
==10183==     in use at exit: 209,042 bytes in 2,764 blocks
==10183==   total heap usage: 924,026 allocs, 921,262 frees, 56,553,314 bytes allocated

==10183== LEAK SUMMARY:
==10183==    definitely lost: 352 bytes in 1 blocks
==10183==    indirectly lost: 3,056 bytes in 21 blocks
==10183==      possibly lost: 0 bytes in 0 blocks
==10183==    still reachable: 205,634 bytes in 2,742 blocks
==10183==         suppressed: 0 bytes in 0 blocks
==10183== Reachable blocks (those to which a pointer was found) are not shown.
==10183== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==10183==
==10183== For lists of detected and suppressed errors, rerun with: -s
==10183== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
 

And this is the portion of valgrind output after I ran the binary under valgrind for about 60 seconds:
==10245== HEAP SUMMARY:
==10245==     in use at exit: 215,890 bytes in 2,800 blocks
==10245==   total heap usage: 1,152,687 allocs, 1,149,887 frees, 54,421,989 bytes allocated

==10245== LEAK SUMMARY:
==10245==    definitely lost: 592 bytes in 2 blocks
==10245==    indirectly lost: 9,664 bytes in 56 blocks
==10245==      possibly lost: 0 bytes in 0 blocks
==10245==    still reachable: 205,634 bytes in 2,742 blocks
==10245==         suppressed: 0 bytes in 0 blocks
==10245== Reachable blocks (those to which a pointer was found) are not shown.
==10245== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==10245==
==10245== For lists of detected and suppressed errors, rerun with: -s
==10245== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2)
 

So my questions are: Should I be worried about it? Are the leaks caused by SFML itself or any other library that SFML is dependant on?

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Re: Memory leak in SFML 2.5.1 hello world program in Ubuntu 20.04
« Reply #1 on: January 03, 2022, 01:09:00 pm »
I've seen so many false-positives over the years, that unless someone can actual pin it down to some SFML source code, I doubt it's SFML related. Graphics drivers are quite well known for having leaks or at least appearing so.

I'm not saying that SFML can't possibly have a leak, but history has shown that it's more likely a graphics diver leak. If you can track it down further, we might have a closer look.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/