SFML community forums
Help => General => Topic started by: alphazeeno on April 25, 2011, 07:48:58 pm
-
I'm currently experimenting with SFML and testing to see if it satisfies the needs of a small project I'm working on. However, when experimenting with it, I seem to run into a memory leak issue that I am unable to root out.
The memory leak is rather small (around 4KB every few seconds). However, the project I'm working is rather sensitive to performance, and this could become an issue later on. I came here to ask if this is just an issue with SFML 1.6 or is something wrong with my code? This is the code I have:
Main.cpp:
#include "Proto.h"
int main(int argc, char* argv[]) {
Proto *proto = new Proto();
proto->Initialize();
proto->Run();
return 0;
}
Proto.h:
#ifndef _PROTO_H
#define _PROTO_H
#include <stdio.h>
#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>
#include <SFML/System.hpp>
#include <SFML/Audio.hpp>
#include "Primitives.h"
using namespace sf;
class Proto {
private:
RenderWindow *window;
public:
void Initialize();
void Run();
};
#endif
And Proto.cpp:
#include "Proto.h"
using namespace sf;
void Proto::Initialize() {
printf("Initializing Proto Simulator ... Done!\n");
this->window = new RenderWindow(VideoMode(400, 400, 24), "Proto Test", Style::Close, WindowSettings(24, 8, 4));
this->window->UseVerticalSync(true);
}
void Proto::Run() {
printf("Running ...\n");
Shape circle = Shape::Circle(100, 100, 20, Color(255, 0, 0));
while (this->window->IsOpened()) {
Event e;
while (window->GetEvent(e)) {
if (e.Type == Event::Closed)
window->Close();
}
window->Clear(Color(255, 255, 255));
window->Draw(circle);
window->Display();
}
}
-
If your project is sensitive to performance, I suggest you try switching to SFML2. Your will have (much?) better performance and if the problem you're mentioning is a bug, it's likely that been fixed in SFML2 :)
There are no big code changes anyway, so I suggest you give it a try.
-
You use new although inappropriate, you don't have a single delete, and you wonder about memory leaks? ;)
I doubt that there is a continous memory leak in SFML. Try to reduce your code to a minimal example, so that you are able to isolate the piece of code which leads to memory that is not deallocated. And please get rid of your own leaks, none of your new expressions is justified.
By the way, how can you be sure that there is a leak?
-
Thank you for the quick responses!
As Mjonir suggested, I switched to SFML2, and that didn't do much. I have to say looking at the API, I do like SFML2 even more.
As for my problem, I shuffled my code around a bit and stripped it down to the bare minimum as Nexus suggested. Here's the new Proto.cpp:
#include "Proto.h"
using namespace sf;
void Proto::Initialize() {
printf("Initializing Proto Simulation ... ");
Application.Create(VideoMode(400, 400), "Proto Test");
Application.EnableVerticalSync(true);
Application.SetFramerateLimit(30);
printf("Done!\n");
}
void Proto::Run() {
Event e;
while (Application.IsOpened()) {
while (Application.PollEvent(e)) {
if (e.Type == Event::Closed)
Application.Close();
}
Application.Clear(Color::White);
Application.Display();
}
}
The problem seems to arise in "Application.Display()". Omitting this call, fixates memory usage of the program. I'm assuming Application.Display() swaps the buffers, and I'm curious as to why this is happening if that is the case.
I've let the program run for about an hour, and the memory usage has gone from 12,200 K to about 28,000 K (as read from Windows Resource Monitor). And it increase (on average) in 4 K increments.
And that is a good question, Nexus. Would you even classify that as a leak? While I do have a decent experience with C++, I wouldn't say I'm very knowledgeable when it comes to low-level operations.
Also, I don't have any deletes because there is nothing to delete! I don't have a single pointer and I did my best to not declare anything inside the main loop.
-
You actually had two pointers in the first example that you didn't delete (Proto *proto and RenderWindow *window) but they have nothing to do with the leak.
I tried the shorter version and all seems to be fine for me. I'm running Ubuntu 10.10 x64 and my memory usage hasn't gone up although I have kept it running for almost an hour. I gotta try the same with Windows later.
EDIT:
I have Ati Mobility Radeon HD 5650 btw.
-
SFML 2 doesn't leak as far as I know. Memory leaks often occur in the OpenGL driver.
-
You actually had two pointers in the first example that you didn't delete (Proto *proto and RenderWindow *window) but they have nothing to do with the leak.
I tried the shorter version and all seems to be fine for me. I'm running Ubuntu 10.10 x64 and my memory usage hasn't gone up although I have kept it running for almost an hour. I gotta try the same with Windows later.
EDIT:
I have Ati Mobility Radeon HD 5650 btw.
SFML 2 doesn't leak as far as I know. Memory leaks often occur in the OpenGL driver.
Could it actually be because of the graphics card or the OpenGL driver? I remember when I used to work with pure OpenGL, I had similar issues...but back then I also had much less experience in C++ and memory management.
I guess my question now is "Is this an issue with my code, SFML, or something beyond my control"?
So far it looks like it's the latter. And if so, that'd be fine.
-
So I had to take a little bit of a break from this project. But now I'm back on it, and I am just absolutely stunned by this memory issue. After playing with it some more, I decided to strip down every thing to the bare minimum. In my project, I have the following 'main.cpp':
#include <SFML\Window.hpp>
#include <SFML\Graphics.hpp>
using namespace sf;
int main(int argc, char* argv[]) {
RenderWindow mWindow;
mWindow.Create(VideoMode(800, 600), "SFML TEST");
mWindow.SetFramerateLimit(20);
Event e;
while (mWindow.IsOpened()) {
while (mWindow.PollEvent(e)) {
if (e.Type == Event::Closed)
mWindow.Close();
}
mWindow.Clear();
mWindow.Display();
}
return 0;
}
Now there are other files and functions in this project, but that is my main.cpp, and it's not referencing anything outside SFML. When I run this program, I see a steady increase in memory usage by monitoring "Memory (Private Working Set)" in the Task Manager.
To further troubleshoot this, I created a new, Empty project. I copy-pasted that same exact main.cpp into the new, empty project, and set up the environment for SFML just like I did for the old project. Just to show you guys, this is my new main.cpp, which is identical to the last one:
#include <SFML\Window.hpp>
#include <SFML\Graphics.hpp>
using namespace sf;
int main(int argc, char* argv[]) {
RenderWindow mWindow;
mWindow.Create(VideoMode(800, 600), "SFML TEST");
mWindow.SetFramerateLimit(20);
Event e;
while (mWindow.IsOpened()) {
while (mWindow.PollEvent(e)) {
if (e.Type == Event::Closed)
mWindow.Close();
}
mWindow.Clear();
mWindow.Display();
}
return 0;
}
What's so puzzling is that this new code does not increase the memory usage! It stays at a constant value relatively and I see no sign of any memory leak!!!
How is this possible?!??!! :shock:
The codes are identical, and I've haven't modified any default Visual Studio (2010) settings in both projects.
If anyone could explain why this could be happening, please explain it to me, as I'm out of ideas.
-
Do you have globals in your project?
-
Not at all. It's just a very simple collection of classes. Nothing is declared outside of that.
I even went as far as commenting out ALL of my other files, all my #include statements, etc etc, and I still get this behaviour! I cleaned the project, rebuilt it, same problem.
There is practically nothing that could be called within the main loop other than SFML, and nothing is being declared outside of it.
The only troubleshooting step that comes to my mind now is to put a print statement in each and every function that I've written, and see if anything is being executed that shouldn't. I'll update this thread if I find the time to do that.
-
The only troubleshooting step that comes to my mind now is to put a print statement in each and every function that I've written, and see if anything is being executed that shouldn't. I'll update this thread if I find the time to do that.
There's a much simpler solution: remove all the files from your project, except the one containing main().
If you still have the leak, then make a diff between both project files to see if they are really identical.
-
There are 1000 chances of making leaks implicitly. For example while initializing static member variables. To do this one just need to compile a unit with a leak.
Lets create a simple header file "a.h":
class B
{
int* a;
public:
B(int val) { a = new int(val); }
~B() { // forget to destroy a }
};
class A
{
static B b;
};
And "a.cpp" that is added to the project:
#include "a.h"
B A::b = 10;
Finally the main() function that neither includes nor does anything. But we have 4-bytes leak due to initializing a static member.
int main(int argc, char* argv[])
{
return 0;
}
I know this example seems too-oo-o unreal. I just wanted to show one of 1000 chanses. And to point that looking at one main() function may not help.
-
There are 1000 chances of making leaks implicitly. For example while initializing static member variables.
I think this is the only one, actually.
And that's why I was asking if he had globals (including class statics) in his code ;)
-
There are 1000 chances of making leaks implicitly. For example while initializing static member variables.
Not if you use RAII to manage your memory automatically. Using manual memory management (i.e. explicitly deallocating with delete) is not worth the trouble most of the time.
-
I'm just speechless. :|
I made a backup of my project. I manually excluded all the files from the project except main.cpp. I went in and deleted those files. I went through every single setting for the Project, and everything is perfectly matched between my old project and the new test project. Both are identical, I checked and double checked. There is only one main.cpp and they're both copies of one another. I manually copy-pasted the file itself. I cleaned and rebuilt everything.
Yet...
When I run the old project, it shows up as taking ~20MB and increases at a steady pace.
When I run the new project, it shows up as taking ~13MB and it remains relatively fixed.
(http://img151.imageshack.us/img151/636/vcs.th.png) (http://imageshack.us/photo/my-images/151/vcs.png/)
(http://img716.imageshack.us/img716/3935/appse.th.png) (http://imageshack.us/photo/my-images/716/appse.png/)
Those two screenshots are screenshots of my solutions side-by-side, and the applications running side by side.
I'm just...I don't...am I going insane? XD
-
Can you upload both projects + sources so that we can look at them?
-
Of course. Here's something else that's even more bizarre.
I just finished adding all the files from my old project to the new one. I set it up so that the new project is now like the old one...
And there is no leak... :|
Anyways, I've attached both solutions.
Proto (old project): http://www.filedropper.com/proto_2
Test (new project): http://www.filedropper.com/test_5
-
In one of them you're not linking to sfml-audio.
-
Right. That addresses why one was using bigger memory, and thanks for pointing it out. :)
But the leak issue is still there...I've been playing with it more, without any conclusive results...
-
What happens if you swap the project files? This will show you if the leak is caused by a project flag or by source code.
-
What happens if you swap the project files? This will show you if the leak is caused by a project flag or by source code.
What do you mean by swapping the project files? You mean swapping the files between Test and Proto? I'll try that, but I doubt it'd give any result, since the files in Test are copy-pasted from Proto.
Update: I just trying swapping the files from Test to Proto, and it didn't solve the issue.
I'm curious however, did you try running these solutions yourself? If so, did you get the same behavior?
-
I'm curious however, did you try running these solutions yourself? If so, did you get the same behavior?
Nop, I don't have Visual Studio 2010.
Update: I just trying swapping the files from Test to Proto, and it didn't solve the issue.
So the problem is in the source code. Why don't you remove all the files from your project, to keep only main.cpp?
By the way, which is the one that leaks? Test or Proto?
-
I'm curious however, did you try running these solutions yourself? If so, did you get the same behavior?
Nop, I don't have Visual Studio 2010.
Update: I just trying swapping the files from Test to Proto, and it didn't solve the issue.
So the problem is in the source code. Why don't you remove all the files from your project, to keep only main.cpp?
By the way, which is the one that leaks? Test or Proto?
Proto is the one that leaks. And I did remove all the files from my project, as shown in the screenshot I posted earlier. I made a back up of my project and physically deleted all the files but main.cpp from the project, and the issue persisted.
-
Ok, so can you upload the project files that contain only main.cpp?
By the way, you don't need to physically delete the files, removing them from the project is enough ;)
-
I know. I just wanted to make sure. :P
Anyways, here's the files of the Proto solution with ONLY the main.cpp. The main.cpp should be identical to the Test solution. Yet this one (Proto with ONLY main.cpp) also shows signs of leaks.
http://www.filedropper.com/protoonlymaincpp
Also, another thing I tested, that might prove useful:
I decided to use VLD (vld.h) to see if it detects any memory leaks or not.
The interesting thing is that VLD said there are no leaks for ANY of the solutions (Proto, Test, and Proto with only main.cpp). And yet the windows Task Manager says otherwise.
Could it be that this issue is just Windows being dumb? Still though, even if that was the case, why wouldn't this happen for the Test Project?
-
I think VLD only tracks leaks that happen in your own source (it overloads malloc/free and new/delete -- for what I've seen).
-
I think VLD only tracks leaks that happen in your own source (it overloads malloc/free and new/delete -- for what I've seen).
So does this mean that the issue is not with me own source?
-
So does this mean that the issue is not with me own source?
Most likely.
Anyways, here's the files of the Proto solution with ONLY the main.cpp
This one still links to sfml-audio.
-
This one still links to sfml-audio.
The Release build shouldn't have that link. The Release build is what I've used for all these solutions, as I had some issues trying to get the debug version of SFML 2.0 to work/compile properly.