Huge memory leak when restarting Irrlicht...

[agamemnus]

OK, so I finally managed to get the fullscreen<->windowed toggle working in-game. Problem is that there's a huge 25 megabyte memory leak...

Does not everything get deallocated when I close the device?

Here's my close function:

Code: Select all

void IrrStop( void )
{
 device->closeDevice();
 device->clearSystemMessages();
 device->run();
 device->drop();
 /* release resources managed by the wrapper and not irrlicht */
 dropShaders();
}


[Zurzaza]

why are you calling the run() function of the device? This function will also returns a boolean value, indicating the current status of the device.
About the memory leaks...you didn't provide enough code to prove that memory leaks are releated to the irrlicht engine, i don't think so...maybe you forgot to delete some pointers...
And what about dropShaders() function?

To find memory leaks in your program, you can use Visual Leak Detector, that gives you a lot of information about...

[greenya]

I don't think that there is a leak.
My tests with the small app example which i wrote for my .NET wrapper doesn't show memory leak, the app which i talking about is at http://irrlicht.sourceforge.net/phpBB2/ ... 967#228967 (look second screenshot) -- any time user changes settings (choose the driver, background, aa) i shutdown thread with Irrlicht device and start new one, which recreate new device with new settings.

The only problem which i have is: when i recreate OpenGL driver with different AA setting once i starting get null from createDevice() all the time once it failed ... all other drivers continue creating OK ... but for OpenGL i need to restart app (and only then OpenGL creates OK again for awhile).

[Acki]

why are you calling the run() function of the device?

you'll have to call it after closeDevice otherwise it won't close the device correctly...
this doesn't matter if you also close the program like in the examples, but if you want to create a new device and keep the program running you'll have to call it...

[robmar]

I stepped through calling run after calling closedevice, and it does nothing, as the close boolean flag is false and it just returns.

I´m also tracking a huge memory leak after running for 8 hours on Win7/Irrlicht/OpenGL, some 400 MB of resources get burned, don´t yet know why, but will post once resolved...

[robmar]

Okay, I have a leak related to the number of meshes I load.

With 500 meshes, I get this level of leak reported by checkmemory in Visual Studio:-

0 bytes in 0 Free Blocks.
230440 bytes in 3163 Normal Blocks.
-532 bytes in -1 CRT Blocks.
0 bytes in 0 Ignore Blocks.
29528 bytes in 1232 Client Blocks.
Largest number used: 278785 bytes.
Total allocations: 681742 bytes.

Any ideas anyone?

[CuteAlien]

How should we have any idea without the code to see what you are doing? Right now we can't even tell if you miss a drop somewhere or if it is something in Irrlicht. We obviously don't know of any leaks in Irrlicht - otherwise we would have fixed them. Please post a complete program that reproduced the leak - this is the only way we have a chance of figuring out what is going on.

[robmar]

Okay okay, sorry, it was just a comment following the other one above, which mentions meshes and having to set flags to have them in hardware (GPU) memory. Not sure what flags those are, or if it was a real problem, or since fixed.

I´ll post my mesh loading code tomorrow, with more exact information and a comparison of leaks DX <> GL.

Is there anyway I can relate those Client block leaks to the Irrlicht code? A more precise memory debugger for Visual Studio 2010?

[CuteAlien]

There is a way... but I don't remember it right now. Could be it involved adding some define at the start - but google for it - it is possible to get VS to report the lines (it reports the lines with the new - the real reason for the leak might still be in another place like forgetting a drop, but it helps).

[REDDemon]

what about adding a static reference counter to IReferenceCounter? Only for debug mode, after running the program one can just check its value to see if there's someting still grabbed.

[hybrid]

Static reference counter? We have the grab count in IReferenceCounted. So simply check whether it's != 0 and you're sure the entity is not deleted properly. OTOH, you should be careful with accessing the objetcs after deletion...
Back to the topic: For Windows event handling to properly process the close window message you have to call run once more, as this will invoke the event handler. Otherwise the window can be stuck on the desktop as a kind of zombie process until the main application terminates. We have had this in our test suite until recently (and still to some extent in the 1.7 branch) where all tests are called in separate processes from the main application. This lead to hundreds of open windows until the main application terminated.

[robmar]

Thanks for the info, and yes you´re right, device->Run does call PeekMessage, and then checks for an external window, etc., so I guess maybe that call is required.

One annoying problem I have yet to solve is that if I use the opengl driver (on Win7), my MFC application hangs up on closing the View, for some reason between exiting OnDestroy there is a 5 second delay before the MFC framework calls the document destructor. Why should the opengl driver cause the MFC framework to perform differently to the D3D driver? I´ve stepped thro MFC, but whatever is happening is in Microsoft´s core code which I don´t have source for. Under D3D with identical meshes etc., the view closes instantly, but if I switch the device to opengl, MFC get hung for 5+ seconds on closing the view. My code closes and deletes the device in the standard manner, and that works perfectly, but for some frustrating and still obscure reason, the MFC framework hangs, originating from the PostMessage issued by MFC after the user clicks the "X" to close the view, that starts the close sequence.

What difference could using OpenGL make to MFC?

[REDDemon]

Static reference counter? We have the grab count in IReferenceCounted. So simply check whether it's != 0 and you're sure the entity is not deleted properly. OTOH, you should be careful with accessing the objetcs after deletion...
Back to the topic: For Windows event handling to properly process the close window message you have to call run once more, as this will invoke the event handler. Otherwise the window can be stuck on the desktop as a kind of zombie process until the main application terminates. We have had this in our test suite until recently (and still to some extent in the 1.7 branch) where all tests are called in separate processes from the main application. This lead to hundreds of open windows until the main application terminated.

yes but if he lost all references to an object he can't check the reference counter because it has no reference to that object. But memory is still allocated . So a static variable can be accessed everywhere to see if there is something that needs to be deallocated(just before returning the main() ) even if no references to an allocated object are available (can happen when forgetting to drop).

[CuteAlien]

In short - static wouldn't be for checking the reference count of an object but to check the number of reference-counted objects. Which could indeed be an interesting number.

[REDDemon]

yes I mean the sum of all reference count. I didn't explained it well ^^