Irrlicht 1.8. Application not closing and memory leak...

You discovered a bug in the engine, and you are sure that it is not a problem of your code? Just post it in here. Please read the bug posting guidelines first.
CuteAlien
Admin
Posts: 9734
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: Irrlicht 1.8. Application not closing and memory leak...

Post by CuteAlien »

Problem in this thread right now is that this are 2 different problems likely.

@ christianclavet: Do you have something to reproduce it?
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
ACE247
Posts: 704
Joined: Tue Mar 16, 2010 12:31 am

Re: Irrlicht 1.8. Application not closing and memory leak...

Post by ACE247 »

Just to check, I tested this on my Linux box(I know this was about windows etc). I can't find any leaks or troubles at all, except for some odd behaviour of the application slowly loading an extra 200kb (100kb every 1 second for 2 seconds) into memory after the scene has already comletely loaded and I haven't moved around at all! And in the Demo example 500kb at 100kb/second starting at 52.6 going to 53.1Mb.(Just simple system monitor stuff) Oddly enough when I put Vsync on, it starts at 52.6 slowly goes up to 53.1 then pops back down to 52 and stays around there. This happens only when using OpenGL driver, not with any of the software drivers. I haven't looked into it much but It also doesn't seem to be much of an issue as it stops quite soon.

Edit: Also tested on my Windows 7 system, with MSVC2010 Irr-svn and 1.8 using GL driver and and I just can't reproduce the Topics mentioned issue.

Edit2: @Christian Clavet, do you mean tbw's postprocess framework, If so which src are you using? I The latest I can find I cant even get to compile on my linux pc with either 1.8 or svn OR 1.7.3. And I know tbw originally built his framework with an irr svn version on windows, its only titled as 1.8.0-alpha. So either his compiler did something weird, or something was different in one of those older 1.8 svn versions for him to get anything to work.
Last edited by ACE247 on Thu Nov 15, 2012 7:31 pm, edited 1 time in total.
robmar
Posts: 1125
Joined: Sun Aug 14, 2011 11:30 pm

Re: Irrlicht 1.8. Application not closing and memory leak...

Post by robmar »

that´s interesting, in my MFC app on Win 7 with nvidia/intel/optimus opengl driver, I´m seeing a 12 MB jump after I start cycling an empty scene, after about 2 seconds.

if I test the same code with the same empty scene on an Intel system with GMA3100 graphics, I get a 2MB leak that appears during the first 1 or so seconds.

Why should nvidia opengl show a 12 MB jump, and Intel show just a 2 MB jump?

Of course my apps MFC, could it be related to how OpenGL handles resources tied to the window?

Do I need to call wglShareLists like the sample?
robmar
Posts: 1125
Joined: Sun Aug 14, 2011 11:30 pm

Re: Irrlicht 1.8. Application not closing and memory leak...

Post by robmar »

Just checked again, and the Win32 leak test shows a 500 KB leak but only when running in debug mode on VS2010, which doesn´t tell us much.

I´ll have to do the MFC-based version to see if that has any impact.

Frustrating that with Intel´s OpenGL driver I get a 2MB leak, but with nVidia a 12 MB leak... strange!

I´m running the Irrlicht code within a separate thread using the MFC window handle, any ideas about OpenGL memory usage issues in regards to MFC windows with Irrlicht in a separate thread?
robmar
Posts: 1125
Joined: Sun Aug 14, 2011 11:30 pm

Re: Irrlicht 1.8. Application not closing and memory leak...

Post by robmar »

I think I may have found the issue.

I tried reusing the same MFC window, and just recycling the Irrlicht engine.

If I create one MFC window, then run create, begin-end scene cycles, destroy engine loops, and repeat, there are NO LEAKS.

But, when I finally destroy the MFC window, and not the app, 12 MB of OpenGL resources are lost with the window!

And, if I do the loop but also destroying and remaking the MFC window, I get a 12 MB leak each loop!

So for some reason, with MFC and Irrlicht run from a non MFC thread, opengl resources are being leaked.

That is to say that OpenGL allocates a framebuffer and stuff for the MFC window that never get released.

But why?
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Re: Irrlicht 1.8. Application not closing and memory leak...

Post by hybrid »

I have the strong feeling that you monitor some hw driver related ressources here. That's no Irrlicht issue
Dareltibus
Posts: 115
Joined: Mon May 17, 2010 7:42 am

Re: Irrlicht 1.8. Application not closing and memory leak...

Post by Dareltibus »

Just do a global counter on IReferenceCounted (well I stolen the idea to someone else on this forum couldn't remember who, but worked very well for find leaks in my code).
I edited the reference counted class to also increase/decrease a global counter (that starts at 0 and is increased by 1 by every grab and is decreased by every drop.. of course now constructor call "grab" instead of just setting the variable to 1).

I fixed all my leaks this way and I can says that if there is a leak. is not reference counted stuff. Both with irrlicht 1.7.4 and irrlicht 1.7.3 and irrlicht 1.8.0 the global counter when program terminates is 0. (also tried to check reference count in "hello world" and other 2/3 irrlicht examples.)

Code: Select all

 
int main()
{
//..N irrlicht's device creations.
//..N irrlicht's device destructions.
//...
return IReferenceCounte::getGlobalCounter(); //always exit with 0.
}
 

so no leak in reference counted stuff. Probably there's some other kind of leak. maybe this can be of any help
robmar
Posts: 1125
Joined: Sun Aug 14, 2011 11:30 pm

Re: Irrlicht 1.8. Application not closing and memory leak...

Post by robmar »

great idea, also saw, that, and you´re right, will do that and see what comes up... that will help show if its my app or the driver...
Nadro
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Re: Irrlicht 1.8. Application not closing and memory leak...

Post by Nadro »

@Dareltibus
This is really interesting idea. Maybe we should implement it in the engine core in some way?
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
robmar
Posts: 1125
Joined: Sun Aug 14, 2011 11:30 pm

Re: Irrlicht 1.8. Application not closing and memory leak...

Post by robmar »

Turns out its not such an easy mod to the engine because all the IReference functions etc are Const, and the counter is of a type that allows const function to vary it, but then if you use a global not a static, which you can´t in a const function,.... and if you change the class declarion from Const then you have to edit all the headers in Irrlicht *sigh*

any ideas?
REDDemon
Developer
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

Re: Irrlicht 1.8. Application not closing and memory leak...

Post by REDDemon »

Nadro wrote:@Dareltibus
This is really interesting idea. Maybe we should implement it in the engine core in some way?
the idea theorically should be mine, already suggested it several times on this forum.

And actually I'm using already this idea in a game project.

Actually in my game:

IReferenceCounted.h (comments stripped out for clarity of the code)

Code: Select all

 
#ifndef __I_IREFERENCE_COUNTED_H_INCLUDED__
#define __I_IREFERENCE_COUNTED_H_INCLUDED__
 
#include "irrTypes.h"
 
namespace irr
{
    class IRRLICHT_API IReferenceCounted
    {
    public:
 
        IReferenceCounted(): DebugName(0), ReferenceCounter(1)
        {
           increaseGlobalCounter();
        }
 
        virtual ~IReferenceCounted(){
 
        }
 
        void grab() const{
            ReferenceCounter++;
            increaseGlobalCounter();
        }
 
        bool drop() const{
            _IRR_DEBUG_BREAK_IF(ReferenceCounter <= 0);
            _IRR_DEBUG_BREAK_IF(getGlobalCount() <= 0);
 
            ReferenceCounter--;
            decreaseGlobalCounter();
 
            if (!ReferenceCounter)
            {
                delete this;
                return true;
            }
 
            return false;
        }
 
        s32 getReferenceCount() const{
            return ReferenceCounter;
        }
 
        static void increaseGlobalCounter(); // implementation into Cpp file
        static void decreaseGlobalCounter(); // implementation into Cpp file
        static s32 getGlobalCount(); //implementation into Cpp file
 
        const c8* getDebugName() const  {
            return DebugName;
        }
 
    protected:
        void setDebugName(const c8* newName){
            DebugName = newName;
        }
 
    private:
        const c8* DebugName;
        static s32  GlobalCounter; //HERE'S GLOBAL COUNTER
        mutable s32 ReferenceCounter;
    };
 
} // end namespace irr
 
#endif
 
 
 
CReferenceCounted.cpp

Code: Select all

 
 
#include "IReferenceCounted.h"
namespace irr
{
    s32 IReferenceCounted::GlobalCounter = 0; //initialize global counter
 
    void IReferenceCounted::increaseGlobalCounter()
    {
        GlobalCounter++;
    }
 
    void IReferenceCounted::decreaseGlobalCounter()
    {
        GlobalCounter--;
    }
 
    s32 IReferenceCounted::getGlobalCount()
    {
        return GlobalCounter;
    }
}
 
you need to pay some attention, moving code into Cpp file is very important, without that the "GlobalCounter" will duplicate (in the meaning that irrlicht classes compiled into the DLL will use a different globalcounter respect to the one the user will have). In an early version of the game I exploited that to see if there were a memory leak into a my class or an irrlicht class, in later version I simply used a non duplicated GlobalCounter ( the exploit was caused by wrong usage of DLL wich gave me nice chance to see interesting things, so I posted only the safer version.

usage:

Code: Select all

 
int main()
{
    //your game
    //...
     _IRR_DEBUG_BREAK_IF( IReferenceCounted::getGlobalCount() != 0); //program terminates here if any memory leaks reported!
     return 0;
}
 
at least on irrlicht 1.7.3 (still haven't any time to upgrade) there are no leaks.
But I can't says for sure since I'm really using few things of irrlicht (GUI and rendering is totally
custom since i'm testin my engine and using irrlicht only for creating windows, handling
keyboard input and reading xml files.). There are no leaks in code I'm actually using. (And anyway my irrlicht 1.7.3 dll is not the original
one, since I applied some changes to the code, mostly patches, including ktx loader, other fixes I applied from bug trucker since
I had not time to wait for 1.7.4 release.. and probably other changes, really played a lot with that code.. nice to see released 1.8.0 XD)

exploited version: (DON'T USE THIS even if at a first look seems usefull. There are evil things that can be wrong, for example I'm under
windows, if same does not apply to linux? since I have not linux and can't test it I dropped immediatly this code when I realized.)

everything in one header except for "getGlobalCount()"

Code: Select all

 
IReferenceCounted()
            : DebugName(0), ReferenceCounter(1)
        {
            GlobalCounter++;
        }
 
void grab() const { ++ReferenceCounter; ++GlobalCounter; }
 
bool drop() const
        {
            // someone is doing bad reference counting.
            _IRR_DEBUG_BREAK_IF(ReferenceCounter <= 0)
            _IRR_DEBUG_BREAK_IF(GlobalCounter <= 0)
 
            --ReferenceCounter;
            --GlobalCounter;
            if (!ReferenceCounter)
            {
                delete this;
                return true;
            }
 
            return false;
        }
 
s32 getGlobalCount(); //still moved to a cpp file compiled into the DLL.
 

Code: Select all

 
#include <IReferenceCounter.h>
irr::s32 irr::IReferenceCounted::GlobalCounter = 0; //required to inizialize twice since is duplicated!
 
int main()
{
     _IRR_DEBUG_BREAK_IF( IReferenceCounted::getGlobalCount()!= 0);
    _IRR_DEBUG_BREAK_IF( IReferenceCounted::GlobalCounter != 0); 
    return 0;
}
 
Last edited by REDDemon on Sun Nov 18, 2012 11:02 pm, edited 3 times in total.
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
Nadro
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Re: Irrlicht 1.8. Application not closing and memory leak...

Post by Nadro »

@REDDemon
Thanks for showing details about it :) Now I'm waiting for Hybrid and CuteAlien comments in this case.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
serengeor
Posts: 1712
Joined: Tue Jan 13, 2009 7:34 pm
Location: Lithuania

Re: Irrlicht 1.8. Application not closing and memory leak...

Post by serengeor »

I actually use this kind of reference counter myself, with some more additional stuff. Helps to spot if something wrong happens after you add new code to a correctly working one.
Working on game: Marrbles (Currently stopped).
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Re: Irrlicht 1.8. Application not closing and memory leak...

Post by hybrid »

You can skip the whole cpp stuff. The methods don't need to be static, nor defined in a cpp file at all. And the static global member can be initialized in one call as 'static int counter=0'. Moreover, I don't see a reason for the methods at all. Just increment the variable directly, the function calls just add huge overhead. If this does not work for you, you did something wrong IMHO.
robmar
Posts: 1125
Joined: Sun Aug 14, 2011 11:30 pm

Re: Irrlicht 1.8. Application not closing and memory leak...

Post by robmar »

But a constant member function cannot modify any data members or call any member functions that aren't constant, so can that work?
Post Reply