What about memory leaks?

[freekill]

Hi!

I have problem, with memory leaks.

I created medium project, when I notice that i had many memory leaks...
Iam deallocating all memory, but mem leaks are still.

I try to google it, and I tried with easy example with Creating window.

This code also have memory leaks.

#define CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#include <SFML/Graphics.hpp>

using namespace sf;
int main()
{
        sf::RenderWindow App(sf::VideoMode(640, 480), "Leak");
        sf::Event zdarzenie;
        while (App.isOpen())
        {

                while (App.pollEvent(zdarzenie))
                {
                        if (zdarzenie.type == Event::Closed || (zdarzenie.type == Event::KeyPressed && zdarzenie.key.code == Keyboard::Escape))
                        {
                                App.close();
                        }
                        App.clear();
                        App.display();
                }
        }
        _CrtDumpMemoryLeaks();
        return 0;
}

 

Mem leaks:

Detected memory leaks!
Dumping objects ->
{211} normal block at 0x042EB718, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{210} normal block at 0x042EB6D0, 8 bytes long.
 Data: <  FR    > DC 91 46 52 00 00 00 00
{209} normal block at 0x042EB650, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{208} normal block at 0x042EB608, 8 bytes long.
 Data: <h FR    > 68 91 46 52 00 00 00 00
{207} normal block at 0x042EB588, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{206} normal block at 0x042EB540, 8 bytes long.
 Data: <h FR    > 68 8E 46 52 00 00 00 00
{205} normal block at 0x042EB4C0, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{204} normal block at 0x042EB478, 8 bytes long.
 Data: <  FR    > F4 8D 46 52 00 00 00 00
{203} normal block at 0x042EB3F8, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{202} normal block at 0x042EB3B0, 8 bytes long.
 Data: <  FR    > F4 8A 46 52 00 00 00 00
{201} normal block at 0x042EB330, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{200} normal block at 0x042EB2E8, 8 bytes long.
 Data: <  FR    > 80 8A 46 52 00 00 00 00
{199} normal block at 0x042EB268, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{198} normal block at 0x042EB220, 8 bytes long.
 Data: <  FR    > 80 87 46 52 00 00 00 00
{197} normal block at 0x042EB1A0, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{196} normal block at 0x042EB158, 8 bytes long.
 Data: <  FR    > 0C 87 46 52 00 00 00 00
{195} normal block at 0x042EB0D8, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{194} normal block at 0x042EB090, 8 bytes long.
 Data: <  FR    > 0C 84 46 52 00 00 00 00
{193} normal block at 0x042EB010, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{192} normal block at 0x042EAFC8, 8 bytes long.
 Data: <  FR    > 98 83 46 52 00 00 00 00
{191} normal block at 0x042EAF48, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{190} normal block at 0x042EAF00, 8 bytes long.
 Data: <  FR    > 98 80 46 52 00 00 00 00
{189} normal block at 0x042EAE80, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{188} normal block at 0x042EAE38, 8 bytes long.
 Data: <$ FR    > 24 80 46 52 00 00 00 00
{187} normal block at 0x042EADB8, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{186} normal block at 0x042EAD70, 8 bytes long.
 Data: <$}FR    > 24 7D 46 52 00 00 00 00
{185} normal block at 0x042EACF0, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{184} normal block at 0x042EACA8, 8 bytes long.
 Data: < |FR    > B0 7C 46 52 00 00 00 00
{183} normal block at 0x042EAC28, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{182} normal block at 0x042EABE0, 8 bytes long.
 Data: < yFR    > B0 79 46 52 00 00 00 00
{181} normal block at 0x042EAB60, 64 bytes long.
 Data: <N   o       J   > 4E 00 00 00 6F 00 00 00 20 00 00 00 4A 00 00 00
{180} normal block at 0x042EAB18, 8 bytes long.
 Data: <<yFR    > 3C 79 46 52 00 00 00 00
{177} normal block at 0x042EA798, 20 bytes long.
 Data: <8r_ 8r_ 8r_     > 38 72 5F 00 38 72 5F 00 38 72 5F 00 01 00 CD CD
{176} normal block at 0x04208D08, 24 bytes long.
 Data: <X               > 58 F6 10 04 FF FF FF FF 00 00 00 00 00 00 00 00
{175} normal block at 0x03E7F7E8, 40 bytes long.
 Data: <  FR            > 20 12 46 52 10 00 00 00 00 00 00 00 00 00 00 00
{173} normal block at 0x005F2D08, 40 bytes long.
 Data: <  FR            > 20 12 46 52 10 00 00 00 00 00 00 00 00 00 00 00
{152} normal block at 0x005F7540, 24 bytes long.
 Data: <xu_             > 78 75 5F 00 FF FF FF FF 00 00 00 00 00 00 00 00
{151} normal block at 0x005F74B0, 24 bytes long.
 Data: < t_             > E8 74 5F 00 FF FF FF FF 00 00 00 00 00 00 00 00
{149} normal block at 0x005F7360, 24 bytes long.
 Data: < s_             > 98 73 5F 00 FF FF FF FF 00 00 00 00 00 00 00 00
{148} normal block at 0x005F72D0, 24 bytes long.
 Data: < s_             > 08 73 5F 00 FF FF FF FF 00 00 00 00 00 00 00 00
{147} normal block at 0x005F7288, 8 bytes long.
 Data: < vFR    > 14 76 46 52 00 00 00 00
{146} normal block at 0x005F7238, 20 bytes long.
 Data: <  .   .   .     > 98 A7 2E 04 98 A7 2E 04 98 A7 2E 04 01 01 CD CD
{145} normal block at 0x005F71F8, 4 bytes long.
 Data: <    > 0D 00 00 00
{144} normal block at 0x005F71B8, 4 bytes long.
 Data: <    > 0C 00 00 00
Object dump complete.
 

I updated my graphic drivers to the latest version, but it didnt help.

My graphic card is RADEON HD 7770.

[ChronicRat]

This is incorrect. You list leaks when your objects are alive.
Use this code in the very begining:

// enable memleak detection
#if defined(_DEBUG) && defined(WINDOWS)
        int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );
        tmpFlag |= _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF;  // Check heap alloc and dump mem leaks at exit
        _CrtSetDbgFlag( tmpFlag );
        assert( !errno );
        //_crtBreakAlloc = 101;
#endif
 

This will autmatically list all the leaks on program exit.

[freekill]

Hmm i use this method to detect leaks :

https://msdn.microsoft.com/pl-pl/library/x98tx3cf.aspx

I tried your method, but it didnt list leaks:

#if defined(_DEBUG) && defined(WINDOWS)
int tmpFlag = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);
tmpFlag |= _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF;  // Check heap alloc and dump mem leaks at exit
_CrtSetDbgFlag(tmpFlag);
assert(!errno);
_crtBreakAlloc = 101; // or //_crtBreakAlloc
#endif
#include <stdlib.h>
#include <crtdbg.h>
#include <vector>
#include <SFML/Graphics.hpp>
using namespace sf;
using namespace std;
class A
{
private:
        int a;
public:
        A(int _a)
        {
                a = _a;
        }
};

int main()
{
        vector <A*> vec;
        A *ob;

        ob = new A(4);
        vec.push_back(ob);
        sf::RenderWindow App(sf::VideoMode(640, 480), "Leak");
        sf::Event zdarzenie;
        while (App.isOpen())
        {

                while (App.pollEvent(zdarzenie))
                {
                        if (zdarzenie.type == Event::Closed || (zdarzenie.type == Event::KeyPressed && zdarzenie.key.code == Keyboard::Escape))
                        {
                                App.close();
                        }
                        App.clear();
                        App.display();
                }
        }

        return 0;
}
 

What do i wrong?

[eXpl0it3r]

At best you learn about RAII and smart pointers and stop worrying about memory leaks.

SFML uses internally some global states which only get deleted when the application exits. So if you really must, check that your tool takes that into consideration.

[ChronicRat]

In the very begining of "main" function! =) And it won't list leaks because your code hasn't them.

[ChronicRat]

At best you learn about RAII and smart pointers and stop worrying about memory leaks.

I think that newbie programmer must avoid use of smart pointers - he has to understand what they do. But he can read about RAII, sure.

[ChronicRat]

And change

#if defined(_DEBUG) && defined(WINDOWS)

to

#ifdef _DEBUG

I'm sure that you have no WINDOWS definition.

[freekill]

And it won't list leaks because your code hasn't them.

I dont delete objects from vector, so it should be leak there...

And change

#if defined(_DEBUG) && defined(WINDOWS)

to

#ifdef _DEBUG

I'm sure that you have no WINDOWS definition.

It dont work.

Can you type the finally version?

[Jesper Juhl]

I dont delete objects from vector, so it should be leak there...

True. You store raw pointers to heap allocated objects in your vector which the vector won't delete when it is destroyed (it would if they had been std::unique_ptr's instead), so you are technically leaking them when the program terminates.
But unless the destructors of the objects allocated on the heap actually have important jobs to do at process termination time, then this theoretical "leak" is completely without consequence, since as soon as your program exits the operating system kernel will reclaim all memory (and other resources) that the program allocated.
Actually, "leaking" objects on purpose when terminating an application is a well known optimization trick to shut down faster by bypassing destructors if it is known that they don't do any work that is persistent between runs of the application (not that I'm advocating that one does that without good reason and full knowledge of the consequences; I'm just pointing out that it's a well known technique).

So, in a nutshell: if you do this in main:

new char(1024*1024*1024);

and then return from main, then yes, you technically leak 1 gigabyte, but that leak only lasts milliseconds until the program is gone and the kernel has reclaimed the memory. It's not like that gigabyte is now lost forever.

[ChronicRat]

I dont delete objects from vector, so it should be leak there...

Yep, I didn't noticed it. So, there is only one thing left - you are not in DEBUG mode.

[freekill]

Yep, I didn't noticed it. So, there is only one thing left - you are not in DEBUG mode.

oh wait i delete that underlined, and after that it show mem leak.


It helps. TY all for replies. Close topic. I dont have any Mem leak in my project now im sure.

[ChronicRat]

Comment _crtBreakAlloc or you will get break point on this allocation.
For example you have this leak:

{195} normal block at 0x042EB0D8, 64 bytes long.

By setting _crtBreakAlloc to 195 program will stop in the line of allocation. Very useful thing, but not always can help (50/50).

[eXpl0it3r]

I think that newbie programmer must avoid use of smart pointers - he has to understand what they do. But he can read about RAII, sure.

Well I disagree. You can learn modern C++ without having to learn C or "old" C++. The memory model can equally well be taught with smart pointers.

[Jesper Juhl]

I agree 100% !

[Jabberwocky]

At best you learn about RAII and smart pointers and stop worrying about memory leaks.

I've noticed a few SFML team members are huge advocates of smart pointers.  Enough so, that I've spent some time reevaluating my own decision to avoid their use in my current game project.  I wondered if maybe I was just entrenched in my ways, and resisting change for no good reason.  "I've always done it this way (raw pointers), and it works" kind of thing.  I even did some research on the performance of raw pointers over smart pointers, hoping to find some smoking gun which would justify my use of raw pointers, but that didn't stick.  There is some small performance gain, but certainly not enough to justify ignoring smart pointers altogether.

Here's what I've finally come up with.  Using raw pointers is certainly more dangerous.  But I find that danger forces me to think more carefully about memory management and ownership in my code.  I can feel some eyes rolling as I type that.  But here's an analogy which maybe you can get behind.  A big reason I choose something like SFML over Unity is that I am forced down an inefficient and more "dangerous" route in creating my game.  I'm working closer to the metal.  I'm intentionally taking the harder path in order to shape my code, and my game in a precise fashion. 

Let's say you wanted a model ship.  You could either build it yourself, at a ridiculous cost-benefit ratio, or buy one for cheap.  But there is value in the building of it, even if it crashes (heh) down on you 10 times before you get it right.  Once you do get it right, it is a thing of beauty; you know every timber, every nail, every knot of that model ship.

That's how I feel about using raw pointers.  I have the "luxury" of being the only coder on my project, so it's less likely some noob junior programmer is going to walk in and trash the place.  Because of reasons like that, I would never argue against using smart pointers.  It certainly makes your code more robust to bad programming habits and errors.  But I think there is a case to be made for avoiding them, too.  It's not like before the advent of c++11, boost, and smart pointers all software was buggy crap.  It just took a little more finesse and expertise to make it work.

I may change my tune on this in the future.  But I figured I'd share my thoughts on smart pointers as of today.