Another goofy problem

[CrazyEddie]

Hi,

Can I ask which OS and compiler this is on? And also, can you give me a rough date for the CEGUI code base you're using?

It could be wierdness with the Ogre memory manager, though usually this initself points to the fact there are problems elsewhere.

Thanks,

CE.

[CrazyEddie]

This sounds like you could be getting bitten by a problem caused by a missing virtual dtor in part of the new event system code. This bug has been fixed, so another update from CVS may well fix this for you.

[Slicky]

I am getting a similar problem after a CVS update today:

Code: Select all

delete CEGUI::System::getSingletonPtr();

causes

Code: Select all

  /* verify block type */
            _ASSERTE(_BLOCK_TYPE_IS_VALID(pHead->nBlockUse));

in dbgdel.cpp

I don't think it is me but could be I guess I did have memory errors after clean building after cvs then moved cegui.h to the top of my includes and everything runs fine but on exit and cleanup I get the above.

[Xothin]

Unfortunately, everyone is getting this ATM.

This is due to the move to the Ogre Memory Manager. There is a thread posted actually that describes the issue and the quick and dirty fix. (Basically its disabling the Ogre Memory Management system)

Until then, either live with it as I do til CE and _mental_ come up with a fix, or follow the instructions on the thread.

[Slicky]

I use OGRE so maybe I should use the nomemorymacros trick to get try and fix it.

[CrazyEddie]

This is unfortunately more of an 'internal' (or should that be infernal ) issue. Using the nomenorymacros trick will probably not solve the assert; the best solution at the moment is to disable the Ogre memory manager and recompile

CE.

[gcarlton]

I'm guessing this is a problem with memory which is allocated by one system and freed on the other (e.g. alloced by the client, freed by cegui).

Have you considered overriding new and delete to call user-overriden functions? For example, ode has malloc/free functions that can be provided by the client code, and every single allocation uses those two functions - well almost, a couple of container resizes slip past sometimes.

To do it right would also mean some trickiness with stl as well (writing a stl allocator class to provide to every single container class constructor, so those allocs are also handled properly).

Alternatively, there could be a general policy for allocs, e.g. all on cegui side. I wonder how many cases there are of news on the app side - I recall listbox items are one at the moment, but if there aren't too many they could be changed to a more factory approach inside cegui.

[CrazyEddie]

The problem was that memory was allocated by Ogre under its memory manager and later freed by CEGUI base which does not use any memory manager.

The problem is now fixed though.

CE.

[gcarlton]

Can you clarify on how it was fixed?

[CrazyEddie]

Of course

Basically it involves copying the buffer returned by the Ogre resource manager into a second buffer allocated using the Xerces memory manager, the original buffer is immediately released via Ogre. The copied buffer can then be released without incident by Xerces or CEGUI.

CE.