Page 1 of 1

Problem with WindowManager::getSingleton vs. getSingletonPtr

Posted: Thu Jun 05, 2008 00:25
by quasius
Hi. I've been using CEGUI 0.5 fine now for months. Suddenly today, I began having strange problems with crashes. The problem seems to be related to the WindowManager::getSingleton() function. I've started getting weird crashes after calling that function in new code I'm writing (which does nothing unusual that I haven't done before. Basically grabbing windows and getting/setting properties) At some "culprit" point, I call getSingleton() and it works, but it seems to corrupt CEGUI somehow since it crashes on future operations. Commenting out the "culprit" getSingleton() call fixes it.
I tried upgrading to 0.6, but had the same problem.
Then I tried using WindowManager::getSingletonPtr() instead and now it seems to work. I'd never paid attention to the getSingletonPtr call since I'd been using getSingleton() ever since I worked the tutorial examples.
The only reasonable thing that I can see might have triggered this is adding more windows to my layout xml file. I have a good 50 windows at this point that I hide and show as needed using the visible property, but I can't image I'd be stressing CEGUI to breaking with 50 windows.
I could just use getSingletonPrt() and try not to think about it, but my code base suddenly becoming unstable obviously worries me.
Is there any known explanation for this behavior?
Thanks.

Edit: Completely forgot the error messages. (They seem to be somewhat arbitrary once CEGUI gets "corrupted" anyway.)

*A debug assertion "ms_Singleton" during a call to CEGUI::System::getSingleton().renderGUI();

*A debug assertion "ms_Singleton" during a call to CEGUI::WindowManager::getSingleton();

*A debug assertion "map/set iterator not incrementable" during a call to CEGUI::System::getSingleton.injectMouseButtonUp();

Posted: Thu Jun 05, 2008 07:14
by earthsruler
So if you simple call getSingleton() and perform no operations on the returned data you get a crash? That shouldn't happen unless you are calling it before the system gets initialised. Try calling

Code: Select all

CEGUI::WindowManager& windowManager = CEGUI::WindowManager::getSingleton();

In debug (so it doesn't get optimised out) and see if it is just the call that is crashing

Posted: Thu Jun 05, 2008 15:28
by quasius
After the "corrupting" call to getSingleton() (which works), it crashes soon after on some arbitrary call to CEGUI. In my testing, I did see it crash on the line (in debug):

Code: Select all

CEGUI::WindowManager windowManager = CEGUI::WindowManager::getSingleton();

To be clear, at this point, I'm suspecting this is buggy behavior in CEGUI and not my not knowing how to use it. It's possible I did something to cause this, although I can't image what since I'm not doing anything new or elaborate. And if I somehow did cause this, this is an extremely ungraceful way for CEGUI to crash.

Posted: Thu Jun 05, 2008 18:42
by CrazyEddie
quasius wrote:After the "corrupting" call to getSingleton() (which works), it crashes soon after on some arbitrary call to CEGUI. In my testing, I did see it crash on the line (in debug):

Code: Select all

CEGUI::WindowManager windowManager = CEGUI::WindowManager::getSingleton();

This code is incorrect, it is attempting to copy the singleton WindowManager object - 'windowManager' should be a reference to the CEGUI::WindowManager.

quasius wrote:To be clear, at this point, I'm suspecting this is buggy behavior in CEGUI and not my not knowing how to use it.

While this is not beyond the realms of possibility, it is made rather unlikely by the large number of CEGUI users compared to the number of people raising this particular issue.

CE

Posted: Thu Jun 05, 2008 19:14
by quasius
CrazyEddie wrote:
quasius wrote:After the "corrupting" call to getSingleton() (which works), it crashes soon after on some arbitrary call to CEGUI. In my testing, I did see it crash on the line (in debug):

Code: Select all

CEGUI::WindowManager windowManager = CEGUI::WindowManager::getSingleton();

This code is incorrect, it is attempting to copy the singleton WindowManager object - 'windowManager' should be a reference to the CEGUI::WindowManager.

quasius wrote:To be clear, at this point, I'm suspecting this is buggy behavior in CEGUI and not my not knowing how to use it.

While this is not beyond the realms of possibility, it is made rather unlikely by the large number of CEGUI users compared to the number of people raising this particular issue.

CE


Thanks. I thought those 2 lines were identical. Sorry if I came off as arrogant there, wasn't my intention.
All this time I didn't realize you had to explicitly declare a variable a reference to correctly receive a reference... So I guess CEGUI just got tired of copying itself after a certain size.

Posted: Thu Jun 05, 2008 20:05
by CrazyEddie
quasius wrote:Sorry if I came off as arrogant there, wasn't my intention.

No problemo, text based mediums are not always the best means of expression and it's easy to come over other than intended, as I know all too well; some people believe I'm a pompous ass - can you believe that? :lol:

quasius wrote:So I guess CEGUI just got tired of copying itself after a certain size.

Really we should be denying the assignment and copy of these singleton objects, I'm not sure why we don't have that protection in place - definitely something I think I'll look into, as the compiler could then give a hint that something is not being done as expected.

CE.

Posted: Thu Jun 05, 2008 23:30
by earthsruler
You should make the constructor private for the managers, then there is no way that that that line would even compile :). Private constructors are cool. It just cuts flexibility off at the knees so that people cant even write potentially dangerous code.

Posted: Sat Jun 07, 2008 08:04
by CrazyEddie
earthsruler wrote:You should make the constructor private for the managers, then there is no way that that that line would even compile :). Private constructors are cool. It just cuts flexibility off at the knees so that people cant even write potentially dangerous code.

Yeah, absolutely. We have this in some other classes already, not quite sure what the deal was with not doing the same with the manager classes - oh well, will make the change for 0.7.0.

CE.