Does setframelimit have a memory leak in 2.1?

[Lamonte]

Using C++ and after commenting out the line my program stopped increasing in memory by 4kb every second?  With it uncommented it would consistently increase in memory every 4kb which is pretty nuts to me.  This happened using C# too, but I thought it was just my shitty coding that was the issue.  Thought I'd check memory usage with SFML before I got into my game and bam noticed that and I'm not sure if that's normal?

Nothing special in my code:

void Game::run()
{
        //initialize window
        window.create(VideoMode(width, height), name);

        //set framerate
        //window.setFramerateLimit(60);

        //load assets
        loadAssets();

        //game loop
        loop();
}

[eXpl0it3r]

Provide a minimal and complete example.
Also make sure you use the latest master.

[Lamonte]

Went to: https://github.com/SFML/SFML downloaded source configured it using CMake for VS12 '13.  Build the project.  Setup a new project w/ the new libraries and dll's (release build type), using the included folder from the master and everything built correctly, no errors.  Memory for the the .exe file when ran goes up by 4kb every second with the framelimit option set.  OS: Win764, using 32bit compile though.  Comment out the line and it doesn't increase at all.

#include <SFML/Graphics.hpp>

int main()
{

        sf::RenderWindow win = sf::RenderWindow(sf::VideoMode(400, 400), "Mem Leak");
        win.setFramerateLimit(60);

        while (win.isOpen())
        {
                sf::Event event;
                while (win.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed) {
                                win.close();
                        }
                }

                win.clear(sf::Color::Black);
                win.display();
        }

        return 0;
}

[Laurent]

Things you can try:
- replace window.display() with sf::sleep(sf::milliseconds(10))
- remove window.display()

I can tell you for sure that this code does not leak in SFML. It's usually a driver issue, and the above suggestions should confirm it.

[Lamonte]

Things you can try:
- replace window.display() with sf::sleep(sf::milliseconds(10))
- remove window.display()

I can tell you for sure that this code does not leak in SFML. It's usually a driver issue, and the above suggestions should confirm it.

Hmm, still happens and only happens when I uncomment the win.setFrameLimit(60); line.  Going to reinstall my drivers for my gtx 770, but I doubt it's drivers because I sent the files to a buddy and he noticed it increasing too.  I noticed this originally when I used to write using the C# bindings months ago and didn't think anything of it, but yeah now using C++ it's happening.  I'll report back after reinstalling these graphics drivers.

[Lamonte]

Yep nothing has changed.

[eXpl0it3r]

You can take a look at the implementation of setFramerateLimit, as long as sf::sleep doesn't leak nothing will leak.
So you tested sf::sleep?

[Lamonte]

You can take a look at the implementation of setFramerateLimit, as long as sf::sleep doesn't leak nothing will leak.
So you tested sf::sleep?

Built it again, leaks.

#include <SFML/Graphics.hpp>

int main()
{

        sf::RenderWindow win = sf::RenderWindow(sf::VideoMode(400, 400), "Mem Leak");

        while (win.isOpen())
        {
                sf::Event event;
                while (win.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed) {
                                win.close();
                        }
                }

                win.clear(sf::Color::Black);
                win.display();
                sf::sleep(sf::milliseconds(10));
        }

        return 0;
}

Edit:

So the above leaks with win clear/win display and sleep.  If I remove sleep with just win clear/display nothing leaks, if it's just display by itself, it leaks and if it's clear/win display + framelimit it leaks and it leaks

Edit to make the above more clear:

- having just sleep where the window clear/display code is doesn't leak.
- adding the window clear/display back leaks
- removing the sleep function with just window clear and display doesn't leak
- adding setframelimit with the window clear and display leaks
- having just the window.display leaks

[eXpl0it3r]

So does this "leak"?

#include <SFML/System.hpp>

int main()
{
    while(true)
    {
        sf::sleep(sf::milliseconds(16));
    }
}

You said it would increase 4 KiB every second or so, how do you track that? Does it only go up?

[Lamonte]

So does this "leak"?

#include <SFML/System.hpp>

int main()
{
    while(true)
    {
        sf::sleep(sf::milliseconds(16));
    }
}

You said it would increase 4 KiB every second or so, how do you track that? Does it only go up?

No that doesn't leak and how I tracked it?  I watched my windows task manager memory usage increase.  The app's default memory usage would be at like 14,000K then increase by 00,004 K every second.  Now the above does not leak at all it sits at 688K and doesn't move ever.  As I mentioned above it only leaked when I had setframelimit set combined w/ the clear+display window functions or it would leak when I had the sf sleep function combined with the display/clear window functions.  having display/clear window functions without either of those the memory usage would set and sit at the amount it initiated when the application started up.  So yeah combining either of those (framelimit/sleep) with window.clear and window.display gives me a leak.  Having either set without each other does nothing just so happens to leak when paired together.

[eXpl0it3r]

The Windows Task Manager isn't really a useful way to track memory usage. There are a lot of dedicated tools which will not only tell you, if there indeed is a leak, but will also pin point you directly to the code bits which leak.

If it increases 4KiB every second, how far up have you watched it? Does it stop at one point? Does the memory usage drop again at one point?

[Lamonte]

It never stops, I've watched it increase above 2MB before I realized that shouldn't happen and stopped watching it.  Basically like I said above, it increases consistently only when window.clear+display is used with sleep or setframelimit, it doesn't happen when you use either of those without each other.

You also said it's not a reliable way to track memory usage, sure, only problem is the pattern hasn't changed lol.

[eXpl0it3r]

I said, it's not a useful way, since you get zero information on the leak, if it even is a leak.
As I said, get a dedicated tool and figure out where the issue originates from.

[Lamonte]

I said, it's not a useful way, since you get zero information on the leak, if it even is a leak.
As I said, get a dedicated tool and figure out where the issue originates from.

What's a good tool to use?

[Laurent]

So, without win.display(), there's no combination that leaks? It doesn't make sense, because all setFramerateLimit does is to add a call to sf::sleep inside Window::display(). So if it's not the "OpenGL" part of display which leaks, nor sf::sleep, there's nothing else in Window::display() that can leak.

Can you try to find a simple OpenGL program, and check if it leaks too? It can be a pure WGL/Win32 program, or one that uses SDL 2, GLFW, FreeGlut, or whatever.

Don't waste too much time tracking the "leak" with tools, I'm 100% sure that it comes from the driver. Check my suggestions first.

And try to reduce your program more: is the event loop needed to produce the leak? Is win.clear() needed?