Memory leak in SFML master (not occuring in 2.3.2) [WORKAROUND]

[hobby]

Using VS debug heap 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, 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)

Detected memory leaks!
Dumping objects ->
{95} normal block at 0x03A8CE90, 48 bytes long.
 Data: < CK             > 20 43 4B 01 00 00 00 00 00 00 00 00 00 00 00 00
{94} normal block at 0x03A15B78, 8 bytes long.
 Data: <        > CD CD CD CD 90 CE A8 03
{93} normal block at 0x00522020, 48 bytes long.
 Data: < CK             > 20 43 4B 01 18 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.

Tracing the allocations with _CrtSetBreakAlloc():

• new ContextType(NULL) in GlContext::globalInit()
• new sf::Context in getInternalContext()
• new ContextType(sharedContext) in GlContext::create()

EDIT: the leaks were "fixed" by manually calling sf::priv::GlContext::globalCleanup() at the end of main().

[DarkRoku12]

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

[Hapax]

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.

[eXpl0it3r]

::_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.

[hobby]

::_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).

[Nexus]

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.

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...

[hobby]

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.

[hobby]

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.

[DarkRoku12]

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

[hobby]

@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:

• I use Visual Studio's CRT debug facilities, which have the option of automatically creating a memory leaks report file when leaks are present on program exit.
• The mere presence of that file on my HDD tells me that since I last checked, there have been memory leaks in at least one of my runs, and where.

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:

• Those memory leaks are not only memory, but also your destructors are not called. They may have important logic in the future.
• "One-time" leaks tend to become recurring leaks once the library is used in a different way than the original developer was thinking about.
• How can a library user know that these leaks are indeed one-time and do not accumulate, when the SFML team does not even acknowledge their existence? It seems to be a necessary step towards more meaningful discussions.
• The impact of memory leaks on the confidence of users in the reliability of the library.
• Probably more to say, but that should be enough for now.

[DarkRoku12]

::_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:

"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.

[hobby]

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.

[binary1248]

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.