Memory Leak CSFML 2.4

[Léandre]

Hi,

I wanted to know, for each project I've made using CSFML, I've never succeeded to completely free my memory.
Some of the time, using Valgrind, I'm at 140 000 bytes in still reachable, and for my latest projects, I'm around 40 000 not freed still reachable bytes.
It is linked to sfRenderWindow_create, the C++ function called for this : sf::Window::create, it's all the time a little bit more for each leak, for the firsts one, I don't have any clue for the rest ...
If you are interested to help me or have an answer, like "don't worry it's ok you can't do anything about it", here's the valgrind output in attachment.

Thanks in advance.
Léandre.

[MOP]

Hey Leandre

i consider youre using some linux distribution, if youre using valgrind.
I got same little memory leaks with CSFML. I use Dr Memory. I got some leaks with sfRenderWindow & sfView. But it doesnt rly affect me(around 30kb)
But why you want to clear it? If it doesnt affect your application, it is ok. Linux got a MPU, which cleans all Memory at processs termination, like in windows.
An little example, free() doesnt give always the memory back to the OS. This is not guaranteed. That makes the OS himself at process termination.

On the other side, you cant change that maybe. And not every leak that is reported by a memory tool, is a really or dangerous leak.

Maybe read this:
https://stackoverflow.com/questions/273209/are-memory-leaks-ever-ok
https://stackoverflow.com/questions/2975831/is-leaked-memory-freed-up-when-the-program-exits

There also some posts about the memory tools.

Greetz

[dabbertorres]

Keep in mind that (as has been the case in the past) memory leaks found "in" SFML were found to be caused by the graphics driver.

This may be the case.

[MOP]

How to find that out?

My laptop got a iGPU(630) and dedicated GTX1050Ti, when i switch the GPU for running my app, the amount of leaking mem is the same.

As i said, it doesnt affect me. Just for interest.

[dabbertorres]

If you're using a tool like valgrind, and you're tracing call stacks (make sure tracing to dynamic library is enabled, if applicable), you should see a call to the library for your graphics driver as the source of the leak.

It could also be memory that is allocated near the beginning of the application, and not freed until the application is closing.