Potential memory leak SFML2.0?

[Sidar]

Hi,

I'm porting Artemis:gamadu.com/artemis/ to C++ and I am pretty sure I have some leaks left that I'm trying to debug. I decided to make a test game with Artemis and SFML. But I've noticed something strange that comes from SFML:

This is my while loop:

while (window.isOpen()) {
               
                //dt = deltaClock.restart();
               
                sf::Event event;
                while (window.pollEvent(event)) {
                        // Close window : exit
                        if (event.type == sf::Event::Closed)
                                window.close();
                }
               
               
                world.loopStart();
                world.setDelta(deltaClock.restart().asSeconds());
                playerJoy.process();
                movsys.process();
                collider.process();
                // Clear screen
                window.clear();
                //updateSpriteSystem
                spritesys.process();
                // Update the window
                window.display();

               
        }

I look into my taskmanager and notice that my applications memory keeps rising. At first I thought I did something completely wrong with my library. So I took out my stuff leaving the SFML stuff in my test run. At this point memory was still going up.

Now I tried the reverse. And I left out:

               
                sf::Event event;
                while (window.pollEvent(event)) {
                        // Close window : exit
                        if (event.type == sf::Event::Closed)
                                window.close();
                }
               

                window.clear();

                window.display();

               
        }

( yes the while (window.isOpen()) is still present at this point)

And my memory stagnates at 27.30 kb. It doesn't go up or down. It stays exactly the same.
Unfortunately I can't give you any debug data. I simply observed the taskmanager.
It only goes up when using the windows method for pollEvent and clear (or display). I have no idea if other methods of the RenderWindow cause the same .

I hope someone can clarify this.

Edit:
I think there is something with the PollEvent. If I leave out that complete while loop for event polling memory goes up until a certain point and then stagnates. But if I put that while loop back memory continues to go up.

Also I'm using a gamepad to control certain entities. And sometimes my application lags because of it. I test my game for a while. Unplug my controller. Start my application again. And it stutters. Also using a lot of CPU cycles. While the controller is unplugged, I'm still checking with sf::joystick if a button is pressed.
Is this my doing or is there a flaw in the SFML implementation for gamepads/joysticks?

~Sidar

[eXpl0it3r]

Are you using the RC binaries or have you compiled SFML on your own?
There have been multiple reports about SFML 2rc having some memory leaks. You can find another thread with the search function. The leaks should probably not be real leaks since the memory gets freed at exit.
The newest version does not show any leaks on my end. Btw there are many d8ffrent tools that will help you figure out if and where a kemory leak comes from.

[Acrobat]

There is no leaks in sfml 2.0
Check this topic http://en.sfml-dev.org/forums/index.php?topic=8092

[Nexus]

There is now leaks in sfml 2.0

You mean "no leaks"

Still, there shouldn't be a constant increase in RAM usage. Does the task manager allocation stop at some point or grow endlessly?

[Acrobat]

There is now leaks in sfml 2.0

You mean "no leaks"

oops 

[Sidar]

There is no leaks in sfml 2.0
Check this topic http://en.sfml-dev.org/forums/index.php?topic=8092

Yeah been there...nothing that helped me. Also this is C++ we are talking about. Not even Jesus can save you there.

There is now leaks in sfml 2.0

You mean "no leaks"

Still, there shouldn't be a constant increase in RAM usage. Does the task manager allocation stop at some point or grow endlessly?

Well if I keep both the poll event and clear/display function running it goes up, continuously, but also the fastest. If I just keep the clear/display functions running it stops eventually( about 15 mb later ). If I only keep the poll event it keeps growing. I went from 30 mb to 160 mb+ and going( in a 7 minute span). And that was only coming from a simple while loop. Even if I don't draw anything between clear/display.

I even tried running my library code commenting out the SFML calls ( except window.isOpen() ) and the memory stagnates. When I created new Entities memory goes up. But doesn't go up endlessly. It only shows change in what I'm creating.

Like I said my library is not memory leak free. I'm pretty sure I made some flaws. However. My library does not show any signs that memory usage continuously keeps going up.

I tried looking for Memory leak tools. But most of them try to change the definition of new and what not. Tried about 3 of them so far and non will compile. I'm using mingw 4.6.2. ( with C++0x enabled ) And I'm not very much experienced to make changes to those memory leak codes to make them compatible for compilation.

I tried the trial version of C++ Memory Validator. But I can't seem to get the source code to be displayed ( Talking about my own library ).

Also:
Like I mentioned, there seems to be an issue when using a gamepad. Unplugged after plugging it ( or it's the sf::Joystick::isButtonPressed being called regardless of an unplugged controller ). There seems to be some heavy stuttering. Not always though. Just sometimes.

[Laurent]

Can you show a complete and minimal code that reproduces the problem? If it's sf::RenderWindow that leaks, even the minimal code of the doc or tutorials should be sufficient.

[Sidar]

This is essentially my complete code. Without my library objects/functions. There are 2 different things I tried:

1:No event polling loop: Goes up for a while and eventually stops. Goes up by a few kb a sec.

#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>


int main(int argc, char **argv) {
       
        sf::RenderWindow window(sf::VideoMode(800, 600,32), "SFML window");
       
        sf::Clock deltaClock;
        sf::Time dt;

        window.setFramerateLimit(60);

       
        // Start the game loop
        while (window.isOpen()) {
               
               
                window.clear();
                window.display();
               
        }
       
        return EXIT_SUCCESS;
}
 

2: No clear/display call; CPU usage monitored at ~+15%. Goes beyond 100mb. It might stop eventually. But 100mb just for this code?

#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>


int main(int argc, char **argv) {
       
        sf::RenderWindow window(sf::VideoMode(800, 600,32), "SFML window");
       
        sf::Clock deltaClock;
        sf::Time dt;

        window.setFramerateLimit(60);

       
        // Start the game loop
        while (window.isOpen()) {
               
                sf::Event event;
                while (window.pollEvent(event)) {
                        // Close window : exit
                        if (event.type == sf::Event::Closed)
                                window.close();
                }
               
        }
       
        return EXIT_SUCCESS;
}

Both debug build and release build seem to show the same thing. Maybe I'm missing some vital information. But it seem completely unlikely that this loop will cause the application to use more than 100 mega bytes.

[eXpl0it3r]

Either I've missed it, or we're still not sure which exacte SFML 2 version you're using. The RC binaries or your own freshly compiled binaries? 

[Sidar]

Either I've missed it, or we're still not sure which exacte SFML 2 version you're using. The RC binaries or your own freshly compiled binaries? 

Windows 32 bits - GCC DW2 (11.5 MB) ( yeah the RC ones )

Also I forgot to close my application. And watched some Cumminity(Tv Series). It's spiked at 260mb and still rising. There is definitely something going on.

[Laurent]

Unfortunately it's often the graphics driver that leaks. Is it up-to-date? Have you tried to run other OpenGL apps and watch the memory consumption?

[slotdev]

You could also try compiling for something else, e.g. Visual C++ 2010 Express. I did the other day, and I get no problems with memory leaks at all.

Also if your CPU is running at 15% for such as basic program...there is something strange going on. I used a crappy old Celeron 2.1Ghz PC with a 64mb video card as target hardware for our work, and with the latest SFML 2, I get 1% CPU when drawing a 1024x768 graphic @ 30fps.

So, I suspect, it is your video drivers or compiler that has screwed things up, and its repeatedly allocating/deallocating memory or creating new objects and not releasing them. I'd bet money its not an SFML bug, though.

Ed

[Sidar]

Unfortunately it's often the graphics driver that leaks. Is it up-to-date? Have you tried to run other OpenGL apps and watch the memory consumption?

According to my Nvidia updater I'm up to date.  I've tried some other opengl applications. But I can't really deduct anything from them. Obviously memory goes up when more objects are created. But I also have to keep in mind how clean the software is written ( and that's something you can't tell ). However Non of them show the same symptoms as what goes on with SFML. But then again. The clear/display functions eventually stopped going up. Event polling went on forever. It might be a stretch, but it could be something with the gamepad.

You could also try compiling for something else, e.g. Visual C++ 2010 Express. I did the other day, and I get no problems with memory leaks at all.

Also if your CPU is running at 15% for such as basic program...there is something strange going on. I used a crappy old Celeron 2.1Ghz PC with a 64mb video card as target hardware for our work, and with the latest SFML 2, I get 1% CPU when drawing a 1024x768 graphic @ 30fps.

So, I suspect, it is your video drivers or compiler that has screwed things up, and its repeatedly allocating/deallocating memory or creating new objects and not releasing them. I'd bet money its not an SFML bug, though.

Ed

Well yeah that is why it's so weird. It shouldn't be going this high.

I guess this will have to do. I'll update you if anything has changed during my development.

[mateandmetal]

Maybe this article could help:
A Cross-Platform Memory Leak Detector

Is your port going to be available for download? ... I´m interested 

[Sidar]

Maybe this article could help:
A Cross-Platform Memory Leak Detector

Is your port going to be available for download? ... I´m interested 

Yeah...I can't get that library to work. It won't accept the changes being made to the operators. I have no clue on how to fix this. I can compile it  by just adding it to my project. But I can't do #include.

My Artemis port was mainly for learning C++. It's not exactly water proof and needs some redesigns. I want to work on this myself to see how far I will get. I will release it soon though. Pretty much summer vacation right now.

Edit:
Well I just made it public
https://bitbucket.org/stalei/artemiscpp

It's shady, so don't expect much from it.