SFML community forums

Help => General => Topic started by: hobby on February 08, 2016, 10:11:06 pm

Title: Memory leak in SFML master (not occuring in 2.3.2) [WORKAROUND]
Post by: hobby on February 08, 2016, 10:11:06 pm
Using VS debug heap (https://msdn.microsoft.com/en-us/library/974tc9t1.aspx#BKMK_Check_for_heap_integrity_and_memory_leaks) on the tutorial program, I get memory leaks in SFML master that do not occur in version 2.3.2.

The code is copied verbatim from the tutorial (http://www.sfml-dev.org/tutorials/2.3/start-vc.php), with the addition of
#include <crtdbg.h>
and
::_CrtSetDbgFlag(::_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
as the first line of main().

I use Windows 32 bit, VS 2012 Express, SFML & CRT statically-linked (and of course, run Debug version for the test). These leaks do not appear to accumulate over time (at least not in my project), but since they're new you may be interested in them.

(click to show/hide)

Tracing the allocations with _CrtSetBreakAlloc():

EDIT: the leaks were "fixed" by manually calling sf::priv::GlContext::globalCleanup() at the end of main().
Title: Re: Memory leak in SFML master (not occuring in 2.3.2)
Post by: DarkRoku12 on February 08, 2016, 11:29:27 pm
I get memory leaks in SFML master that do not occur in version 2.3.2.

Tracing the allocations with _CrtSetBreakAlloc():
  • new ContextType(NULL) in GlContext::globalInit()
  • new sf::Context in getInternalContext()
  • new ContextType(sharedContext) in GlContext::create()

1) The current version is 2.3.2. If you have the last git-master version you have the 2.3.2.

2) The memory leaks are from the OpenGL's contexts, i believe it must not have importance because this contexts (i believe) should remain until the program has finish. And when the program finish the OS release all the memory allocated by your process.

Check this about memory (http://view.samurajdata.se/psview.php?id=5a7292a1&page=10&size=full)
Title: Re: Memory leak in SFML master (not occuring in 2.3.2)
Post by: Hapax on February 09, 2016, 02:32:02 am
The current version is 2.3.2. If you have the last git-master version you have the 2.3.2.
The latest release version is 2.3.2. The master version on GitHub surpasses that release.
Title: Re: Memory leak in SFML master (not occuring in 2.3.2)
Post by: eXpl0it3r on February 09, 2016, 09:02:17 am
::_CrtSetDbgFlag(::_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
as the first line of main().
SFML has certain global states, so if you start tracking memory allocations only after main() is called, you're already missing things.

To be honest if you stick to modern C++ with RAII memory leak tracking will become obsolete pretty quickly.
Title: Re: Memory leak in SFML master (not occuring in 2.3.2)
Post by: hobby on February 09, 2016, 09:33:06 pm
::_CrtSetDbgFlag(::_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
as the first line of main().
SFML has certain global states, so if you start tracking memory allocations only after main() is called, you're already missing things.
VS debug runtime tracks all memory allocations from the start, including non-local static objects. This line only triggers reporting, so if you moved it to the end of main() you would get exactly the same 3 leaks.
This means that 2.3.2 was not leaking (at least not system/window/graphics).
Title: Re: Memory leak in SFML master (not occuring in 2.3.2)
Post by: Nexus on February 10, 2016, 10:53:34 am
These resources seem to be deallocated correctly, have you made sure that the corresponding code is not reached (by debug output or breakpoints)?

Visual Studio's leak detector stopping too early is as well an issue as starting too late. It cannot see the deallocation after its lifetime, and so it regards such resources as leaked.

Quote
This means that 2.3.2 was not leaking (at least not system/window/graphics).
No, it only means that the VS detector didn't see any leaks for 2.3.2. And this does not imply that master is leaking...
Title: Re: Memory leak in SFML master (not occuring in 2.3.2)
Post by: hobby on February 12, 2016, 05:09:22 am
Well, returning back to the original technical issue discussed...

These resources seem to be deallocated correctly, have you made sure that the corresponding code is not reached (by debug output or breakpoints)?
Now I have, for the two 48-byte leaks. Placing breakpoints in WglContext c'tors and d'tor, it seems that 3 instances are created but only 1 is deleted.

Visual Studio's leak detector stopping too early is as well an issue as starting too late. It cannot see the deallocation after its lifetime, and so it regards such resources as leaked.
Why are you saying that? You don't use #pragma init_seg in SFML, why shouldn't this facility be reliable?

No, it only means that the VS detector didn't see any leaks for 2.3.2. And this does not imply that master is leaking...
Actually I use master of 2.5 months ago, but I believe that nothing has changed in this regard.
Title: Re: Memory leak in SFML master (not occuring in 2.3.2)
Post by: hobby on September 09, 2016, 02:45:08 pm
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 (https://github.com/SFML/SFML/issues/1143)).

For your convenience, I've described in #1143 (https://github.com/SFML/SFML/issues/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.
Title: Re: Memory leak in SFML master (not occuring in 2.3.2)
Post by: DarkRoku12 on September 09, 2016, 07:13:07 pm
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 (https://github.com/SFML/SFML/issues/1143)).

For your convenience, I've described in #1143 (https://github.com/SFML/SFML/issues/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
Title: Re: Memory leak in SFML master (not occuring in 2.3.2)
Post by: hobby on September 10, 2016, 07:06:33 am
@DarkRoku, this is not a semantic discussion regarding memory leaks, but a highly practical one.

Let me tell you straight - I almost never test for memory leaks, even not for recurring ones. That's because I don't need to:
So the practical issue is that SFML's memory leaks create noise that masks other leaks. As I'd been using SFML 2.3.2 for some time, I actually forgot about the file. But now it keeps being created on every run, no matter if there are other leaks or not.

Beyond that, as library developers you may want to consider the following:
Title: Re: Memory leak in SFML master (not occuring in 2.3.2)
Post by: DarkRoku12 on September 10, 2016, 08:08:56 am
::_CrtSetDbgFlag(::_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
as the first line of main().
SFML has certain global states, so if you start tracking memory allocations only after main() is called, you're already missing things.

To be honest if you stick to modern C++ with RAII memory leak tracking will become obsolete pretty quickly.

For few people those leaks is still a several issue, i think that the [url¡http://en.sfml-dev.org/forums/index.php?topic=19106.0]branch[/url] started by Binary1248 could help to solve this ´problem´ in the future.

I agree with most of your points but:
Quote
"One-time" leaks tend to become recurring leaks once the library is used in a different way than the original developer was thinking about.

When this happens you can expect problems.
When a user try to use a tool incorrectly or in a way that was not made for, is common to face problems.
So, if a user want to reach a goal by tricking or misusing SFML, better to search another library to fill its needs.
Title: Re: Memory leak in SFML master (not occuring in 2.3.2)
Post by: hobby on September 10, 2016, 11:52:26 am
Well, I've looked into it further. Fixed everything by adding the following at the end of main():

#ifdef _DEBUG
        // fix the following SFML memory leaks:
        // - new ContextType(NULL) in GlContext::globalInit()
        // - new sf::Context in getInternalContext()
        // - new ContextType(sharedContext) in GlContext::create()
        sf::priv::GlContext::globalCleanup();
#endif

As I link statically, no change to SFML was needed, only the following declaration before main():

namespace sf { namespace priv { class GlContext { public: static void globalCleanup(); }; } }

I could've done it earlier if I hadn't relied on the following SFML version for a fix. Will learn next time.
Title: Re: Memory leak in SFML master (not occuring in 2.3.2) [WORKAROUND]
Post by: binary1248 on September 10, 2016, 06:45:18 pm
I could've done it earlier if I hadn't relied on the following SFML version for a fix. Will learn next time.
It's never too late to learn something new.

Just FYI, this is a regression that was introduced in 2.4.0. As such, you never relied on "the following SFML version" for a fix because there still is none.

You can make this statement by the time 2.4.1 is released and if the issue persists, but complaining that something remained broken from a pre-release revision to the first release after said revision is just a sign that nobody cared to thoroughly test or provide feedback regarding the issue during development.

You might say that you already reported it before the release, and while this is true, we prioritize bugs based on their severity which is measured by the number of people that show interest in the issue. It is regrettable that not many other people cared, but rest assured that it will be fixed as soon as possible.