[SOLVED]Live Object with DirectX11

[Tasche]

um is anyone else having problems with live objects?

using the directx 11 debug layer, i get messages of live objects. i only initialize the system and draw a window (as described in the beginner tuts), and that works like a charm too.
the CEGUI.log does not mention anything out of the ordinary, only the resources loaded, no errors or warnings (which is to be expected, since everything works perfectly).
however the library doesnt seem to release COM interfaces properly. for that single window i get 21 unreleased objects. without creating anything (not even a root window), but just loading resources, which is basically the code of beginner tut 1 through 3, i get 13 live objects.

am i missing some shutdown method here?
please don't tell me i am forced to use smartpointers or something. ive got too much code which is 100% unmanaged, so i'd really appreciate some cleanup function.
and if there already are some, make sure to mention them in the beginner tuts

i posted this here already, an admin/mod might want to remove it there, since it is not on topic.

EDIT: after fooling around for a while and checking for live objects i come to the conclusion that the destroy() methods cleans up any windows properly, without leaks. still unsure how to clear everything else.
here a simplified list of live objects and how many (unnamed because they don't have debug names assigned to them):
Buffer: unnamed,1
ShaderResourceView: unnamed,1
Texture2D: unnamed,1
ShaderResourceView: unnamed,2
Texture2D: unnamed,1
InputLayout: unnamed,1
PixelShader: unnamed,1
VertexShader: unnamed,1
PixelShader: unnamed,1
VertexShader: unnamed,1
BlendState: unnamed,1
BlendState: unnamed,1
RasterizerState: unnamed,1
Buffer: unnamed,1
DepthStencilState: unnamed,1
Sampler: unnamed,1

My suggestion: assign debug names via directx's SetPrivateData function by default (in the appropriate CEGUI file) when building the debug version, helps debugging a lot.
also these interfaces need to be released somehow, i cant figure out how.

[CrazyEddie]

Hi,

I have to remember to go easy on the new guy, especially since you posted in the appreciation thread

It's hard to say whether you have to take additional steps to clean up, since you have not shown what you're doing to clean up! Also, please read the red text up there (unless you're reading on some greyscale device), but, seriously, posting your log is really required, it contains so much information that is useful to us (and to put it another way, sometimes the information it does not contain is useful to us).

I'm not aware of any cleanup issues, but then I'm not really using that renderer much (at all), and until recently we did not have support for it in the samples, so it was a pain to set up tests for - so it is possible that some issues exist, although I'd like to think they don't

CE

[Tasche]

first of all, thanks for the reply

mh ok, you are right, never try to outsmart the dev, if he says post log, you better get copypasting! . i completely forgot that the lack of information is also information.
i'm not sure in which format to post my logs so i just used pastebin, since it makes the raw data available.

CEGUI.log
http://pastebin.com/qiwXPJdz
MSVC debugger output:
http://pastebin.com/SaDGYnQX

most of those D3D warnings are irrelevant since there don't contain 'external references'. only those with 'ExtRef=1' or similar are leaks.

what ive done to cleanup:
yeah, thats the thing, i basically do nothing. but that's mostly since i cant find info on cleanup somehow. however, the leaks stem from only loading initial resources (as shown in beginner tut 1-3, code below).
these logs are from a case where i do not even create a root window (i think ). anything i DO create, i can delete via the destroy() method, and that works just fine, no additional leaks whatsoever.

Code: Select all

    m_pgc->ConnectGUI();

    WindowManager& wmgr = WindowManager::getSingleton();
    DefaultResourceProvider* rp = static_cast<DefaultResourceProvider*> (System::getSingleton().getResourceProvider());

    //set CEGUI resource group paths
    rp->setResourceGroupDirectory("schemes", "E:/VCProgs/wc/media/datafiles/schemes/");
    rp->setResourceGroupDirectory("imagesets", "../media/datafiles/imagesets/");
    rp->setResourceGroupDirectory("fonts", "../media/datafiles/fonts/");
    rp->setResourceGroupDirectory("layouts", "../media/datafiles/layouts/");
    rp->setResourceGroupDirectory("looknfeels", "E:/VCProgs/wc/media/datafiles/looknfeel/");
    rp->setResourceGroupDirectory("lua_scripts", "../media/datafiles/lua_scripts/");

    //set default resource groups
    Imageset::setDefaultResourceGroup("imagesets");
    Font::setDefaultResourceGroup("fonts");
    Scheme::setDefaultResourceGroup("schemes");
    WidgetLookManager::setDefaultResourceGroup("looknfeels");
    WindowManager::setDefaultResourceGroup("layouts");
    ScriptModule::setDefaultResourceGroup("lua_scripts");

    //create a scheme and a font in CEGUI
    SchemeManager::getSingleton().create( "TaharezLook.scheme" );
    FontManager::getSingleton().create( "DejaVuSans-10.font" );

    //set default font and mousecursor
    System::getSingleton().setDefaultFont( "DejaVuSans-10" );
    System::getSingleton().setDefaultMouseCursor( "TaharezLook", "MouseArrow" );



the only thing done in connectGUI() method is a call to to CEGUI::Direct3D11Renderer::bootstrapSystem( m_pDev, m_pDevCon ), passing in the appropriate pointers.
i assume the those managers use some directx11 COM interfaces which cause the live objects. btw don't waste to much time on this issue, being able to check the source code, i should find the culprits myself and report back once i find them.
i just thought there are some cleanup functions, which delete any and all connection of CEGUI to directx, which i'm just too stupid to find.

[CrazyEddie]

Yes, the fact that cegui has not cleaned up is related to the fact that you perform no cleanup calls.

i just thought there are some cleanup functions, which delete any and all connection of CEGUI to directx, which i'm just too stupid to find.

When using the 'bootstrapSystem' function to initialise everything, there are correspondeing 'destroySystem' functions to tear it all down again. This is mentioned in the tutorial:

Note that the Renderers also have destroySystem functions for cleaning up afterwards.

CE.

[Tasche]

wow, sorry even bothering you with this...
found the destroySystem() method and its works great, all leaks taken care of. then again i knew that in this professionally maintained code such an obvious oversight was unlikely, but i simply was unable to locate the appropriate functions.
this helped a lot, thanks again.

will be marked as solved