Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Memory leak in SFML master (not occuring in 2.3.2) [WORKAROUND]  (Read 10884 times)

0 Members and 1 Guest are viewing this topic.

hobby

  • Newbie
  • *
  • Posts: 43
    • View Profile
Memory leak in SFML master (not occuring in 2.3.2) [WORKAROUND]
« on: February 08, 2016, 10:11:06 pm »
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)

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().
« Last Edit: September 10, 2016, 11:55:08 am by hobby »

DarkRoku12

  • Full Member
  • ***
  • Posts: 203
  • Lua coder.
    • View Profile
    • Email
Re: Memory leak in SFML master (not occuring in 2.3.2)
« Reply #1 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
« Last Edit: February 08, 2016, 11:31:13 pm by DarkRoku »
I would like a spanish/latin community...
Problems building for Android? Look here

Hapax

  • Hero Member
  • *****
  • Posts: 3346
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: Memory leak in SFML master (not occuring in 2.3.2)
« Reply #2 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.
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
Grambol
 *Hapaxia Links*

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Re: Memory leak in SFML master (not occuring in 2.3.2)
« Reply #3 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.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

hobby

  • Newbie
  • *
  • Posts: 43
    • View Profile
Re: Memory leak in SFML master (not occuring in 2.3.2)
« Reply #4 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).

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Memory leak in SFML master (not occuring in 2.3.2)
« Reply #5 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...
« Last Edit: February 10, 2016, 10:55:23 am by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

hobby

  • Newbie
  • *
  • Posts: 43
    • View Profile
Re: Memory leak in SFML master (not occuring in 2.3.2)
« Reply #6 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.

hobby

  • Newbie
  • *
  • Posts: 43
    • View Profile
Re: Memory leak in SFML master (not occuring in 2.3.2)
« Reply #7 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).

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

  • Full Member
  • ***
  • Posts: 203
  • Lua coder.
    • View Profile
    • Email
Re: Memory leak in SFML master (not occuring in 2.3.2)
« Reply #8 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).

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
I would like a spanish/latin community...
Problems building for Android? Look here

hobby

  • Newbie
  • *
  • Posts: 43
    • View Profile
Re: Memory leak in SFML master (not occuring in 2.3.2)
« Reply #9 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:
  • 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

  • Full Member
  • ***
  • Posts: 203
  • Lua coder.
    • View Profile
    • Email
Re: Memory leak in SFML master (not occuring in 2.3.2)
« Reply #10 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.
I would like a spanish/latin community...
Problems building for Android? Look here

hobby

  • Newbie
  • *
  • Posts: 43
    • View Profile
Re: Memory leak in SFML master (not occuring in 2.3.2)
« Reply #11 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.

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Memory leak in SFML master (not occuring in 2.3.2) [WORKAROUND]
« Reply #12 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.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).