Unloading CEGUI

[sluburob]

Hello,
I'm using CEGUI with MS VS 2012 (self compiled 64 bit with DirectX11).

Everything wors fine and CEGUI is great. I'm near finishing the project. And when it comes to memory Leaks, i have some trouble.

Code: Select all

Detected memory leaks!
Dumping objects ->
{148690} normal block at 0x0000000000487490, 144 bytes long.
 Data: <07/02/2014 17:41> 30 37 2F 30 32 2F 32 30 31 34 20 31 37 3A 34 31
{146273} normal block at 0x00000000048C7D40, 752 bytes long.
 Data: <  R     0 R     > C0 7F 52 04 00 00 00 00 30 EC 52 04 00 00 00 00
{143850} normal block at 0x0000000000435060, 192 bytes long.
 Data: <P A     P A     > 50 B4 41 00 00 00 00 00 50 B4 41 00 00 00 00 00
{143835} normal block at 0x0000000004ADEFE0, 1044 bytes long.
 Data: <P   r   o   g   > 50 00 00 00 72 00 00 00 6F 00 00 00 67 00 00 00
{143824} normal block at 0x0000000004ACC600, 48 bytes long.
 Data: <tl:FFFFFFFF tr:F> 74 6C 3A 46 46 46 46 46 46 46 46 20 74 72 3A 46
{143795} normal block at 0x0000000004ACBCB0, 48 bytes long.
 Data: <tl:FFFFFFFF tr:F> 74 6C 3A 46 46 46 46 46 46 46 46 20 74 72 3A 46
{143660} normal block at 0x0000000004ACC1B0, 144 bytes long.
 Data: <                > 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF
{143655} normal block at 0x0000000004ACBBB0, 16 bytes long.
 Data: <  J             > D0 0E 4A 00 00 00 00 00 06 00 00 00 01 CC CC CC
{143654} normal block at 0x0000000004ACBB10, 48 bytes long.
 Data: <tl:FFFFFFFF tr:F> 74 6C 3A 46 46 46 46 46 46 46 46 20 74 72 3A 46

This, followed by some other megabytes of Data is left in teh Memory. It seems to be a lot from CEGUI, I think that shouldn't be normal behavior.

I think there its just a simple code to execute for unloading. But couldn't find the right lines.
I start CEGUI like this:

Code: Select all

InitD3D();

CEGUI::Direct3D11Renderer &myRenderer = CEGUI::Direct3D11Renderer::bootstrapSystem(dev , devcon );
ceGUIrenderer = &myRenderer;
ResourceProvider = static_cast<CEGUI::DefaultResourceProvider*>(CEGUI::System::getSingleton().getResourceProvider());

ResourceProvider->setResourceGroupDirectory(RES_SCHEMES_NAME, RES_SCHEMES_FOLDER);
ResourceProvider->setResourceGroupDirectory(RES_IMAGESETS_NAME, RES_IMAGESETS_FOLDER);
ResourceProvider->setResourceGroupDirectory(RES_FONTS_NAME, RES_FONTS_FOLDER);
ResourceProvider->setResourceGroupDirectory(RES_LAYOUTS_NAME, RES_LAYOUTS_FOLDER);
ResourceProvider->setResourceGroupDirectory(RES_LOOKNFEELS_NAME, RES_LOOKNFEELS_FOLDER);
ResourceProvider->setResourceGroupDirectory(RES_LUA_NAME, RES_LUA_FOLDER);
      
CEGUI::ImageManager::setImagesetDefaultResourceGroup(RES_IMAGESETS_NAME);
CEGUI::Font::setDefaultResourceGroup(RES_FONTS_NAME);
CEGUI::Scheme::setDefaultResourceGroup(RES_SCHEMES_NAME);
CEGUI::WidgetLookManager::setDefaultResourceGroup(RES_LOOKNFEELS_NAME);
CEGUI::WindowManager::setDefaultResourceGroup(RES_LAYOUTS_NAME);
CEGUI::ScriptModule::setDefaultResourceGroup(RES_LUA_NAME);
CEGUI::SchemeManager::getSingleton().createFromFile( "LvtLook.scheme" );

So waht would be the right unload code? everything i tried was aborting with various Exceptions.
And do I have to delete/unload every single Window i create in CEGUI?

Help is welcome
Best regards from Black Forest Germany
sluburob

[Kulik]

http://static.cegui.org.uk/docs/current ... ab2d216fb6

EDIT: wrong renderer, use this - http://static.cegui.org.uk/docs/current ... e03dd57111

[Ident]

And do I have to delete/unload every single Window i create in CEGUI?

When CEGUI System is destroyed it automatically deletes all windows so you will not need to do that. However, if you create a lot of windows in run-time you will probably want to delete them on your own anyways to reduce the memory usage.

[sluburob]

Thank you for the Quick answer seems destroySystem() works perfect tried before with destroy which resulted in some crashes..

This is good advice to destry Windows which aren't needed anymore. I think i'm doing this in most cases, but will check that again, cause memory is a real issue in my case.

[Ident]

It seems like it is not well documented how to deinitialise CEGUI. I will add this to the doxygen docs in the future.
System::destroy() is the right way to destroy (everything) and should also not cause any crashes or problems.

[sluburob]

Even if it's not well documentetd, Forum Support is great. And i'm one of the few who uses CEGUI with MSVC and DX11.

But I have seen some more Memory Leaks.

first of all, i search for them with:

Code: Select all

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
//and before exit:
_CrtDumpMemoryLeaks();

in some cases i know this method does not work correctly. But hope this is not the Problem here.

This is at the Moment for testing my CEGUI code (Programm starts and exits straight after that.)

Code: Select all

      
ceGUIrenderer = &(CEGUI::Direct3D11Renderer::bootstrapSystem(dev , devcon ));      //   2 memory leaks detected here
ResourceProvider = static_cast<CEGUI::DefaultResourceProvider*>(CEGUI::System::getSingleton().getResourceProvider());

ResourceProvider->setResourceGroupDirectory(RES_SCHEMES_NAME, RES_SCHEMES_FOLDER);
ResourceProvider->setResourc................
............setResourceGroupDirectory(RES_LUA_NAME, RES_LUA_FOLDER);
// set the default resource groups to be used
CEGUI::ImageManager::setImagese............
............ultResourceGroup(RES_LAYOUTS_NAME);
CEGUI::ScriptModule::setDefaultResourceGroup(RES_LUA_NAME);

CEGUI::SchemeManager::getSingleton().createFromFile( "LvtLook.scheme" );     // 5 memory leaks detected in this line

//do nothing and exit
CEGUI::SchemeManager::getSingleton().destroy("LvtLook.scheme");   
ceGUIrenderer->destroySystem();
CEGUI::System::destroy();


I tried to figure out what is beeing allocated with the Call Stack but i'm not that into CEGUI.
Is there anything i'm missing to unload related to CEGUI?

Thanks for your support.

[Ident]

I use the same way of memory leak tracking you use, which is a quite weak but the only free and easy way to do it in MSVC. Unix distros have better solutions like valgrind. It's a real pity there is nothing on Windows for that.

That said: Everytime i noticed leaks it turned out to be my own fault.
I give you a code snipped of what I do to destroy CEGUI in one of my older projects in which I get no leaks at all:

Code: Select all

    CEGUI::System::destroy();
    CEGUI::OpenGL3Renderer::destroy(*m_ceguiOpenGL3Renderer);

I am not sure what CEGUI version it is but this shouldn't have changed anyways. If you dont store a pointer to your renderer you can just retrieve the pointer before you destroy the System.
Mind the order.

[sluburob]

Think it should be

Code: Select all

CEGUI::System::destroy();
CEGUI::Direct3D11Renderer::destroy(*ceGUIrenderer);

still leaks left, nearly the same as with that code:

Code: Select all

ceGUIrenderer->destroySystem();
CEGUI::System::destroy();

What i can say is, that in my case there are leaks with Creating layouts, and loading shemes. And these two leaks with the renderer.
I'll try to go through the Call Stack tonight and search for more detailed info. As for now I think memory is freed when the programm exits. (While running there seems to be no Problem that it "eats" memory)

[Ident]

So the leaks are related to the renderer? that is well possible. I think the D3D renderers were provided by users mostly.

[sluburob]

So perhaps my Idea switching to OpenGL is not that bad.

[Ident]

According to what you said the memory leaks shouldnt cause any issues because they just appear before the program is closed and not during run-time.

Whether OGL or D3D is better depends on what you want to do with your project.

Or did you only mean to switch to OGL for testing where the memory leaks source from?

[sluburob]

Switching to CEGUI for testing would be an Option first.

My Programm has nothing to do with gaming. Therefor with Video Processing in Realtime. At the moment some things Frames are Processed with DX functions and given to textures on CEGUI Static Images. so DX was an easy Option. Cause the most functionalytiy a add is related to cuda, it would be an option to switch to OpenGL because the communication is much better.