SFML community forums
Help => Window => Topic started by: solgar on November 21, 2009, 03:41:50 pm
-
Running following code constantly consumes RAM. Running for 1 minute consumes ~10 mb of memory.
#include <SFML/Window.hpp>
using namespace std;
int main()
{
sf::Window* wnd = new sf::Window(sf::VideoMode(800, 600, 32), "SFML_test", sf::Style::Close|sf::Style::Titlebar|sf::Style::Resize, sf::ContextSettings(32, 8, 0));
while( wnd->IsOpened() )
{
wnd->Display();
wnd->Close();
wnd->Create(sf::VideoMode(800, 600, 32), "SFML_test", sf::Style::Close|sf::Style::Titlebar|sf::Style::Resize, sf::ContextSettings(32,8,0));
}
return 0;
}
Why is that? Code seems to be valid usage of Close() and Create() methods. I am using Xubuntu linux.
-
Hi
I've tested your code and indeed I found a memory leak... on Windows :D
I'll do the same test on Linux.
Thanks for your feedback :)
-
I fixed a leak in the Linux implementation, however valgrind still outputs leaks from XCreatePixmap and XOpenIM, although I properly call the corresponding Free functions. I'm not sure whether or not this is SFML's fault.
-
Hi!
Did you manage do find the leak on windows?
I started using sfml and almost directly ran into this leak by using this code:
#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#endif
#include <SFML/graphics.hpp>
INT WINAPI WinMain(HINSTANCE Instance, HINSTANCE, LPSTR, INT) {
sf::RenderWindow renderWindow(sf::VideoMode(800, 600, 32), "SFML Graphics");
while(renderWindow.IsOpened()) {
// Process events
sf::Event Event;
while (renderWindow.GetEvent(Event))
{
// Close window : exit
if (Event.Type == sf::Event::Closed)
renderWindow.Close();
}
// Fill the background black
renderWindow.Clear(sf::Color(0, 0, 0, 255));
// Display window contents on screen
renderWindow.Display();
}
#ifdef _DEBUG
_CrtDumpMemoryLeaks();
#endif
return EXIT_SUCCESS;
}
Is there a way to fix this issue?
Thank you
- Zerd
*edit*
Sorry its not really related to this topic, I'm using SFML-1.5 for VS2008
-
Did you manage do find the leak on windows?
The one I was talking about previously had been resolved immediately.
Which reversion of SFML2 do you use? Can you show the output of _CrtDumpMemoryLeaks()?
-
Sorry, I'm not using version 2 I'm using 1.5 for Visual Studio 2008 (on a x64 pc)
I suppose I also am in the wrong forum... :( I'm sorry for that...
Detected memory leaks!
Dumping objects ->
{152} normal block at 0x01EE79F8, 16 bytes long.
Data: < } > 0A 00 00 00 82 00 00 00 7D 01 00 00 CC CC CC CC
{151} normal block at 0x01EE79A8, 16 bytes long.
Data: < > 02 00 00 00 CC CC CC CC CC CC CC CC CC CC CC CC
{150} normal block at 0x01EE7948, 32 bytes long.
Data: < y y > A8 79 EE 01 F8 79 EE 01 00 00 00 00 00 00 00 00
{135} normal block at 0x01EE7000, 20 bytes long.
Data: < p p p > 00 70 EE 01 00 70 EE 01 00 70 EE 01 CD CD CD CD
{134} normal block at 0x01EE3D88, 216 bytes long.
Data: <| Q > 7C 15 51 00 01 00 00 00 01 00 00 00 00 00 00 00
{133} normal block at 0x01EE3D48, 4 bytes long.
Data: < = > 88 3D EE 01
Object dump complete.
Thats my problem, it doesn't really say where the memory is leaking...
-
So it's probably the one I fixed above... ;)
-
I just downloaded and built the latest trunk and it's still leaking. So I guess its not the same problem ;)
Detected memory leaks!
Dumping objects ->
{152} normal block at 0x01ED7A00, 16 bytes long.
Data: < > 0A 00 00 00 0D 00 00 00 06 01 00 00 CC CC CC CC
{151} normal block at 0x01ED79B0, 16 bytes long.
Data: < > 02 00 00 00 CC CC CC CC CC CC CC CC CC CC CC CC
{150} normal block at 0x01ED7950, 32 bytes long.
Data: < y z > B0 79 ED 01 00 7A ED 01 00 00 00 00 00 00 00 00
{135} normal block at 0x01ED7000, 20 bytes long.
Data: < p p p > 00 70 ED 01 00 70 ED 01 00 70 ED 01 CD CD CD CD
{134} normal block at 0x01ED3D88, 224 bytes long.
Data: < DQ > 0C 44 51 00 01 00 00 00 01 00 00 00 00 00 00 00
{133} normal block at 0x01ED3D48, 4 bytes long.
Data: < = > 88 3D ED 01
Object dump complete.
-
I'm not sure that I fixed it in the trunk :lol:
-
Doh... OK, I'll try again tomorrow... :)
-
I'm sorry to say that, but with the latest svn version it's still leaking :oops:
-
Latest revision in branches/sfml2?
-
Yes, branches/sfml2
With the same source I posted earlier...
-
What if you remove the calls to Clear and Display?
-
Alone this code creates a leak:
#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#endif
#include <SFML/graphics.hpp>
int main() {
sf::RenderWindow renderWindow(sf::VideoMode(800, 600, 32), "SFML Graphics");
#ifdef _DEBUG
_CrtDumpMemoryLeaks();
#endif
return EXIT_SUCCESS;
}
-
Alone this code creates a leak:
#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#endif
#include <SFML/graphics.hpp>
int main() {
sf::RenderWindow renderWindow(sf::VideoMode(800, 600, 32), "SFML Graphics");
#ifdef _DEBUG
_CrtDumpMemoryLeaks();
#endif
return EXIT_SUCCESS;
}
You didn't Close the window.
-
It closes in its destructor.
-
Microsoft's CRT memory leak detector indeed shows leaks (of course after I put the sf::RenderWindow declaration in a local block; checking something before its destruction is pointless).
I also tested the code with my self-written memory tool. When I called the tool's report functions, three memory leaks were observed (24, 20 and 4 bytes). These are the same ones as the CRT stated. But, according to my trace, that memory is freed – the deallocation took place after my function call, so the memory isn't considered freed at report time. I think, Microsoft's memory dump has got the same problem.
By the way, those alleged leaks came up in the following functions:
- sf::Resource<T>::Resource() – the std::set initialization
- sf::ThreadLocal::ThreadLocal(void*) – myImpl = new priv::ThreadLocalImpl;
- sf::Mutex::Mutex() – myMutexImpl = new priv::MutexImpl;
Obviously, this memory is all correctly deallocated. The above constructors are invoked during program startup, before main(). Therefore, the deallocation is performed at program shutdown, after main().
So: Decide wisely which memory observation tool you want to trust. ;)
-
Thanks Nexus,
I tested it for myself as well again usingn new and delete with the renderWindow. Which got me to the same result (3 leaks)
What I don't understand is why the memory is freed after the dump-call and not directly when renderWindow is destroyd?
I assume RenderWindow creates a thread. So it makes sence that memory is allocated until main() finished and the thread is terminated. But wouldn't it make more sence to kill the thread when the RenderWindow is destroyed (for example after using "delete renderWindow;" )? That way the memory dump should be ok.
I'm just curious if that might be a solution?
-
I tested it for myself as well again usingn new and delete with the renderWindow. Which got me to the same result
This doesn't change anything compared to a stack allocation, the object is still created and destroyed.
What I don't understand is why the memory is freed after the dump-call and not directly when renderWindow is destroyd?
Because it has nothing to do with the RenderWindow. It is related to some global objects that SFML uses. You can test it with an empty main(): the "leaks" will still be there ;)
I assume RenderWindow creates a thread
Absolutely not!
-
Ok, thanks for making that clear :)
No further questions!
Thx