SFML community forums
Help => General => Topic started by: JunkerKun on April 20, 2014, 02:18:49 am
-
Hello again.
I'm not sure where it should be placed so I just put it in general.
Today I found out that when I create and delete objects the memory begins to rise. Now I woldn't be surprised if it was everytime I delete an object (I'd just check my code for leaks) but it doesn't. As far as my tracking went I managed to find out that it has something to do with objects that have textures.
Now the strange thing is that VLD showed only 8 kb of memory leaked while Win7 task manager showed about 10 mb rising.
So is it false positive or is it an error in my code? I'm quite stuck here. Going to look further but would like to hear some ideas.
-
It's usually a driver issue. 100% of memory leaks reports on SFML so far ended up being one.
-
It's usually a driver issue. 100% of memory leaks reports on SFML so far ended up being one.
Hmm.. going to update my driver and check if it has an effect.
-
If you show us some code, maybe even a minimal example that we can try ourselves that reproduces the problem, then we might be able to suggest ways to mitigate the leaking. That the drivers leak is a fact (even with the most up to date ones), you just have to know when they do and try to avoid/reduce doing whatever it is that causes it.
-
If you show us some code, maybe even a minimal example that we can try ourselves that reproduces the problem, then we might be able to suggest ways to mitigate the leaking. That the drivers leak is a fact (even with the most up to date ones), you just have to know when they do and try to avoid/reduce doing whatever it is that causes it.
Well, that is the problem. The leak seems to be occuring when I create a texture but... with the same circumstances but different texture it does not leak (or at least it doesn't show up on "radars")! I'm really confused by this.
Aaaaaand... the code would be too long to post. Besides I still need to trace the exact location where it occurs. I will update when I find at least something.
Update:
Here is the fun thing: lesser a texture is, more noticable the leak becomes. I'm begining to think it is indeed a leak in the driver, not in my code. Can't be too sure though.
-
debug your code and post the function that pointers can't be deleted and we'll fix that for you
i have a recommendation:
use malloc and free
-
i have a recommendation:
use malloc and free
No! I can't even... ::)
Use RAII (http://www.bromeon.ch/articles/raii.html) and don't bother about memory management anymore.
Aaaaaand... the code would be too long to post.
If the code is too long to post, then I'm 99.999999999999999999999% sure it's not SFML's fault, because memory leaks are nearly always reproducible in a very small example.
-
...
i have a recommendation:
use malloc and free
Are you serious?
You are aware that malloc doesn't call constructors and free doesn't call destructors - right?
Also, as has already been mentioned, with modern C++ and RAII it's extremely rare that you have to deal with manual memory management at all.