Page 1 of 1
Another goofy problem
Posted: Mon Oct 18, 2004 07:30
by 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.
Another goofy problem
Posted: Mon Oct 18, 2004 14:39
by 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.
Another goofy problem
Posted: Thu Dec 16, 2004 07:04
by 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.
Another goofy problem
Posted: Thu Dec 16, 2004 07:22
by 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.
Another goofy problem
Posted: Thu Dec 16, 2004 07:36
by Slicky
I use OGRE so maybe I should use the nomemorymacros trick to get try and fix it.
Another goofy problem
Posted: Thu Dec 16, 2004 19:18
by 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.
Another goofy problem
Posted: Sun Jan 09, 2005 20:54
by 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.
Another goofy problem
Posted: Sun Jan 09, 2005 21:08
by 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.
Another goofy problem
Posted: Tue Jan 11, 2005 01:24
by gcarlton
Can you clarify on how it was fixed?
Another goofy problem
Posted: Tue Jan 11, 2005 10:18
by 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.