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

[CuteAlien]

If it's just a few lines you can just paste them with the code tag.

[christianclavet]

Hy, Wow! There have been activity here!

I just want to give more details:

1-I've rebuilded the Irrlicht DLL in RELEASE mode, so the DLL is a release version and not a DEBUG version as I made previously.
2-My application is still compiled and run in DEBUG mode and it's using this DLL. Nothing wrong to report from MSVC, no leaks detected by the compiler.
3-I checked memory usage, after I close and the memory seem to be released back to the system. (quick check using the task manager in Windows)
4-The application was terminated "normally" via the "exit" button.

Could it be that some compiler directives are "blocking" in a way certain stuff to be released and that would cause the leak in the DEBUG version only of the DLL?
Until I know more about this, I simply can't use the DEBUG DLL, but the RELEASE DLL is working really fine and now my application is back to normal and everything seem to work as before and I now have access to all the goodies from the 1.8 version...

I didn't know anything about the opengl leak until robmar talked about it, I was not aware of the problem at all. Hope we see where is going that 12mb. I'm doing all my development in GL as I want my code to be multiplatform.

[CuteAlien]

I guess we have 2 different problems here, I don't know about the first one - would need an example.

I tried reproducing the second one reported by Robmar with the memory-leaks, but could not reproduce it (VS 2010 and compiled for 32-bit in both debug and release). My test-code was the following:

Code: Select all

 
#include <irrlicht.h>
 
using namespace irr;
using namespace core;
 
#ifdef _IRR_WINDOWS_
#pragma comment(lib, "Irrlicht.lib")
#pragma comment(linker, "/subsystem:windows /ENTRY:mainCRTStartup")
#endif
 
int main()
{
    while (1)
    {
        IrrlichtDevice *device = createDevice( video::EDT_OPENGL, dimension2d<u32>(640, 480), 16,
                                    false, false, false, 0);
        if (!device)
            return 1;
 
        device->closeDevice();
        device->drop();
    }
 
    return 0;
}
 

This is not taking up 12 MB (around 9 MB here) and does not increase over time, so I need there an example as well.

[christianclavet]

Hi! Cool! Perhaps it's fixed under 1.8?
For "my" problem, supposing this (I have not used an Irrlicht debug DLL before and would need more precision about this):

As an example:
I don't release some ressources (ex: triangle selectors not released using the selector->drop() method)

Then:
Using the Irrlicht RELEASE DLL would I see a memory leak when I debug my application?
Using the Irrlicht DEBUG DLL would I see a memory leak when I debug my application?
Note: Using either version of the DLL under the application compiled in DEBUG mode and started in MSVC by the debugger.

If the answer is no for the release version, then the problem is in my code, perhaps I don't release something and the debug DLL has debug information for the debugger to show me that something was not released properly, while using the release DLL, I would see nothing.

If I forgot to release stuff and If I use the release DLL, then nothing is detected. So if this impression is correct then I have surely a lot of stuff to fix in the code. Please confirm.

[hybrid]

Mem leaks won't survive the application close. Everything is returned at that point. But if you create several devices, and forget to drop every time, memory usage will increase until you close the application.
Whether debug or release won't make a difference, unless you have the drop call in compile time ifdefs with _DEBUG or something like that. But the MSVC mem checker won't report anything under release (at least not by default). So only debug mode dll will show the problems when closing the application.

[robmar]

The test needs to at least set the engine up and run one cycle to clear the FB.
I´m also using MFC as a test application, but maybe the leak will show with a standard wnd.
The code below is not complete but complete code for creating a win32 Irrlicht sample is here: http://irrlicht.sourceforge.net/docu/example014.html)
Just drop the main test code into place.

// Irrlicht leak tester

Code: Select all

 
#include <irrlicht.h>
#ifndef _IRR_WINDOWS_
#error Windows only example
#else
#include <windows.h> // this example only runs with windows
 
using namespace irr;
using namespace core;
 
#ifdef _IRR_WINDOWS_
#pragma comment(lib, "Irrlicht.lib")
#pragma comment(linker, "/subsystem:windows /ENTRY:mainCRTStartup")
#endif
 
int main()
{
// Add code from sample 14 to create window and add the following test code around where it says "// create irrlicht device in the button window"
.... remove all the scene setup and run loop from the sample, replacing with this:-
 
    IrrlichtDevice *device = NULL;
    irr::SIrrlichtCreationParameters *pParam = NULL;
    IVideoDriver *pDriver;
    ISceneManager *pSmgr;
    SColor sc;
    sc.set( 0xff, 0, 0, 0x32 )
  
    int iLoopCycle = 10;
 
    while ( iLoopCycle-- )
    {
        if ( pParams )
           delete pParams;   // Delete and recreate on each loop
       pParam = new irr::SIrrlichtCreationParameters;
       pParam->AntiAlias = irr::video::EAAM_LINE_SMOOTH;    // 4
       pParam->WindowId = reinterpret_cast<void*>(hWnd);    // From external CWnd (important as OpenFL driver seems to have a problem when using ext windows)
 
      video::SExposedVideoData videodata( hWnd );       // Structure for holding data describing driver and operating system specific data
 
      pParam->DeviceType = EIDT_WIN32;
      pParam->DriverType = video::EDT_OPENGL;       // EDT_DIRECT3D9 EDT_DIRECT3D8 EDT_OPENGL
      //pParam->DriverType = video::EDT_DIRECT3D9;      // EDT_DIRECT3D8 EDT_OPENGL
      pParam->Stencilbuffer = true;     // Needed for shadows
      pParam->Bits = 32;
      pParam->Doublebuffer = true;     // To avoid drawing artifacts
      pParam->Vsync = true;               // If set false, shearing may occur
 
     //pParam->Vsync = true;             // If set false, shearing may occur
      pParam->EventReceiver = NULL;
     //pParam->EventReceiver = &receiver;   // Crashes logger in debug mode with MFC ex Wnd, and otherwise doesn't work from separate thread!
 
      pParam->WindowSize = core::dimension2d<u32>( 1024, 768 );
      pParam->WindowSize = wndsize;     // Set to match current CWnd view
 
      pParam->HighPrecisionFPU = true;   // MUST BE SET TO AVOID MATHS FAILURES EN COLEDATETIME AND POSSIBLY OTHER MS/MFC FUNCTIONS
      pParam->WithAlphaChannel = true;
 
        device = irr::createDeviceEx( *pParam );    // Create 3D engine
        if (!device)
            return 1;
 
       // Get drivers
       pDriver = device->getVideoDriver();
#ifdef _DEBUG
       int iDRC = pDriver->getReferenceCount();
#endif
       pSmgr = device->getSceneManager();
       device->setResizable( true );      // Window is resizeable
       pDriver->setTextureCreationFlag(video::ETCF_ALWAYS_32_BIT, TRUE);
       pDriver->setTextureCreationFlag(video::ETCF_CREATE_MIP_MAPS, TRUE);
       pDriver->setTextureCreationFlag(video::ETCF_NO_ALPHA_CHANNEL, FALSE);    // Use alpha
       if ( !pDriver->queryFeature( video::EVDF_TEXTURE_NPOT ) )        // If non power-2 supported, allow // NOTE: ALWAYS ADJUST TO REDUCE CPU OVERHEAD
          pDriver->setTextureCreationFlag( ETCF_ALLOW_NON_POWER_2 );
 
       device->getTimer()->setTime( 0 );
 
       pDriver->beginScene( true, false, sc );  // Call before rendering, clear screen
       pSmgr->drawAll();
       pDriver->endScene(); // The updated (engine animations only) screen frame now gets presented
 
       device->closeDevice();
       device->run();
       device->drop();
    }
 
     if ( pParams )
        delete pParams; 
   return 0;
}
 

[zerochen]

you have a memleak in your code. pParams was not deleted at the end

[robmar]

yes you´re right! Fixed! Unfortunately its not the 12MB leak I want to find!

[CuteAlien]

*sigh* when you post an example please put at least so much work into it to ensure it compiles and reproduces the bug. The above code has several(!) syntax errors - ergo - never was even compiled. And just post the whole code and no building instructions... that's easier anyway. If it's too long for the forum use: http://ideone.com/ and then post the link.

I just spend 10 minutes fixing it - and then got an application which did not leak - even when I replaced your loop with an endless-loop.

[robmar]

*sigh* I just completed the leak sample based on example 14, and I´m seeing a leak of about 500 KB per engine create/delete cycle but only when running it in debug mode from VS 2010.

If I run it in release mode there is no leak, or maybe very small.

In my app, unlike sample 14, I don´t call wglShareLists, but would that make a difference?

Will post it now. Win 7 32 bit, Visual Studio 10.

[robmar]

Here is the link to the Irrlicht 1.8 engine leak cycle tester sample: http://www.sendspace.com/file/9e70zj

With or without scene content the leak is around 500 KB but only in debug mode. The create/delete cycle speed change causes the leaks to occur faster without content.

So to fix that, paste the following code over the same section in the code, that way the leak occurs at the same rate with or without scene content.

Code: Select all

            while ( device->run() &&  iLoopCycle-- )
            {
                pDriver->beginScene( true, true, sc );  // Call before rendering, clear screen
//              pDriver->beginScene( true, true, sc, videodata );  // Call before rendering, clear screen
                pSmgr->drawAll();
                pDriver->endScene(); // The updated (engine animations only) screen frame now gets presented
 
                Sleep( 1000/50 );       // Maintain cycle rate independent of content loading
            }
 

Tested on Win 7, 32 bit, with VS 2010 in debug mode.

Side comment on Example 14: Not sure what the opengl code for setting wglShareLists is all about, as there is just the one window...

Use Windows Task Manager to view the Process memory usage.

[CuteAlien]

So if I get this right (not on Windows now) the leak is no longer 12 MB but a half MB and it's not in the engine at all but in some opengl initialization code of an example? That starts sounding rather different by now :-) (that's pretty much why we need examples - could never have found about that otherwise)

[zerochen]

hi,

i run your app and only one leak is detected (but it is on your side not irrlichts).

why do you create pParam on the heap? it isn t needed.
just change it to irr::SIrrlichtCreationParameters pParam; and no leak will be detected.

also i m not sure whether you can trust the taskmanager.
use this, it is much better:
http://msdn.microsoft.com/en-us/library/x98tx3cf.aspx

regards
zerochen

[robmar]

The params are created like that because in my app if I reused the engine, and didn´t recreate it, the results were unstable for some reason that I just couldn´t locate.

Its not really relevant though, as both methods should work.

My app uses MFC, so I´ll now make a sample with MFC to test for leaks.

On my app, using OpenGL, when I create the engine, etc., and run one cycle, I have no memory loss showing for the application, but after a number of begin-endscene cycles, there is a sudden 12 MB jump in resources tied to the app.

And during that time my app doesn´t allocate textures, images or anything - I disabled all that code.

Its not happening in my main irrlicht thread, i used memcheck and nothing listed, no leak.

But somehow, somewhere, 12 MB gets eaten up. I could think its something to happening outside of my app, but thats a guess... frustrating really.

[hybrid]

Well, just some days ago it was a massive leak, which occured on every device creation. So then at least every creation should use up 12 more MB, otherwise it's really of no concern at all. Just on mobiles you might get a problem if this 12MB problem would exist, but you also don't have MFC there. So after all, you probably filled more MB with your massive posts than what is actually leaking...