I see that other people keep encountering the same leaks now that 2.4 is released, and that the SFML team is quick to dismiss their reports and mark their issues as closed (see #1143).
For your convenience, I've described in #1143 a simple test that demonstrates that these leaks are real in a manner that does not depend on leak detection tools nor debuggers. I really hope you'll take the time to fix this issue at last.
Don´t need to revive the thread.
I don´t know where exactly those leaks emanates from, but like i said in my first post, seems to be from the OpenGL context.
If SFML need those resources alive until the program has finished then the "leak" is pointless.
Why memory leaks are bad?
1) They hold unnecesary memory, so when the process is still active, malloc/new won´t reuse this memory and because that will request more memory to the system.
2) Having a lot of unnecessary allocations in the heap can fragment it, this can lead to slow down the program runtime.
However, is memory is need until the program terminate, deallocate this memory is
pointless, because the OS keep track of all allocations and when the process finish the OS will reclaim them.
Refer to the attachment from
Memory Allocation Myths and Half−Truths - Hans Boehm