CEGUI (Crazy Eddie's GUI) Forums

Hi all.

Im having a bit of an issue with the event subscriber (ive found so many other posts about this and none of them fixed it)



Debug: In debug mode, the exe dosent even start, it crashes on this line


Output:


Call Stack:


Disassembly



And in Release Mode the client loads fine... BUT when you try and use the button


The callstack and output windows are useless when that happens...

This is my first app with CEGUI, so im just hoping ive done somthing rong haha... im hoping that its no DarkGDK causing this O-o

Thanks in advance for any help you can give
-- Icewave

edit:
i suppose i should add im running windows 64x (but compiling to win32 and running) and using Microsoft Visual C++ 2008 Express SP1

And heres the CEGUI.log file from release mode:

Hi, and welcome

I believe this type of issue is normally related to project configuration.

Check that you're linking the correct libs for each configuration (and only those libs, do not link both debug and release libs at the same time ) - so the static ones for static builds, the ones with the _d suffix for debug builds and so on.

HTH

CE.

I have tripple check this just to be sure but i am using the correct libs (compiled with both 'Release' and 'Debug' modes, not static ect) and the libs are being used in the right modes... im posting screen shots in case im doing something wrong and i dont know it



no idea what atls is, just noticed it... removed it but it didn't make any difference....


Am i right in thinking that the drag, resize and minimize functions on the window by default are events? if thats true then i wonder why mine custom events crash...

All the demo files compile and run perfectly

edit:
Some how ive managed to remove all the library ignores, i dont know how it never used to compile if they were there.. but even so, it still gives the same errors

edit2: I managed to screw around wit the project setting enough to get the game to compile and run in debug mode(and yes its till using debug runtimes), but i get that assertion error


What dose the 'this' in this line for anyway? just thinking here...

Hi,

Yes, the demos and the system in general use the same types of event mechanisms internally as what you would use in your own apps as a user of the library.

If the demo apps built and ran, it definitely indicates either a coding error or a project setup / configuration issue - although identifying specifically what is messed is apparently easier said than done.

The assert is '!ms_Singleton' which is the check done before instantiation; so it may indicate either that you're creating singleton objects more than once, or there is a memory issue. IIRC Jamarr had an issue caused by having modified the structure alignment setting.

Another thing to check is that the c/c++ runtime being used is the correct one. That being the multithreaded DLL version, and obviously the debug version of that for debug builds.

The 'this' pointer in the Event::Subscriber is a pointer to an instance of the class that contains the member function you want called; this is required because you obviously need an instance pointer in order to be able to invoke a member function (also of note is that the object instance passed must not be deleted while the event may still get fired and the handler called).

CE

If all events use the same mechanisms then i wonder why all the internally defined events work fine but the ones i try to define manually fail, very interesting

i tried changing the preprocesser def's but that didn't help either

Is there any way around this? is there a way i can add an event without calling 'subscribeEvent'? or perhaps is the location in my code that im calling that from (but ive tried it in two places... not sure)

Ive tried all 4 different run time library's (/MD /MT /MTd /MDd) all 4 of them crash in almost the same way

/MDd = Assertion error;
/MTd = (wont compile) > Strange... used to be able to compile this
/MD = Assertion error;
/MT = Assertion error;


and whats even strainger, is i cant get to to crash in call anymore... so i guess changing them preprocesser devs have helped a little but wtf is with this assertion error

Is there any way around this?

Yes, of course there is a way around it, since lots of people use the events system every day without issue

I have only a handful of ideas about why you might get the issue you are; unfortunately, and especially with limited information as is always the case with this kind of 'remote' support, I do not always have all the answers to every possible problem.

Do you / are you able to get the assertion failure in debug mode? What does the call stack look like when that happens?

CE

Yes, i can get the assertion failure in debug, and the call stack is completely blank



is what im currently using. The assertion error only happens when i guess it attempts to call the function thats subscribed(without any call stack info its hard to know)

perhaps i should try a different compiler? do you have any recommendations?


edit:

This looks right to me...

Ok i moved all the gui functions to the main function called a the begining of the game and shut down the rest of my game... and ... it works

i think i understand the assertion error... tell me
Dose it expect that GUIManager should be a singleton? dose it expect GUIManager::getSingleton() to exist if so then that explains everthing

Simple fix, ive taken all my gui code out of a class, and just moved it to global functions.


Thank you for all your help Eddie.

Based on the assert message I would say the problem is pretty obvious. You are calling the constructor of one of CEGUI's singleton classes twice (my guess is CEGUI::System).

The assert message gives you the file and line#, so you should be able to find/recognize this yourself as CEGUI is open-source. The assert is being generated because ms_Singleton is already defined (you have already created the object) and you are trying to create it again.

Btw, did you delibratly turn on asserts in a Release Build? They are normally only compiled in for debug-builds.

I would guess that you are calling your GUIManager::CreateGUI() function multiple times? In most cases you should only need to create/initialize CEGUI once.

I am guessing the reason it works when you moved the call into your main function is because that code is only ever executed once.

You see, that's what i thought at first, i thought that it was being called more then once, but went through the code line by line to make sure i wasn't...

if it was it wold make more seance that the game would crash on load, as apposed to when the event is triggered

No i didn't enable asserts manually they were just already active i guess..



i know this is not how the 'this' pointer is suppose to behave... but is it possible that the 'this' pointer in the function call is somehow managing to recall GUIManager::CreateGUI()? perhaps i should try changing it from 'this' to 'GUIManager'... but ill try that tomorrow for now, im off to bed haha

Icewave wrote:You see, that's what i thought at first, i thought that it was being called more then once, but went through the code line by line to make sure i wasn't...

Well, the assert is definitely not wrong. It is being thrown because that is what is happening. The CEGUI::Singleton constructor is being called, the assert triggers because the singleton-pointer, ms_Singleton, has some value already assigned to it. This means either 1) the object has already been created legitly or 2) you either have a corrupt pointer or you are corrupting the heap somewhere.

if it was it wold make more seance that the game would crash on load, as apposed to when the event is triggered

There seems to be some conflicting issues here. Is the assertion triggered when subscribing to the event, or when the event is fired? In your original post, in debug mode it sounds like the assert is being triggered when you subscribe, but in release mode it is not triggered until the event is fired? What's the deal?

Either way, neither of those actions have anything to do with constructing a CEGUI::Singleton. You are either calling CreateGUI() twice, either during load or when an event is fired, or you are corrupting the heap and overwriting some memory that is causing CEGUI::Singleton() to be called.

Have you tried putting a try/catch block around all of the CEGUI calls that can throw exceptions? I do not see any in your code snippets. Typically these would be listed in the log, but you should really try to catch any/all exceptions regardless.

I would also highly recommend creating a log for your own code, so you know exactly what events are taking place and in what order.

No i didn't enable asserts manually they were just already active i guess..

Yeah, I looked at CEGUI's source and they use the assert() method directly instead of the assert macros for some reason...

i know this is not how the 'this' pointer is suppose to behave... but is it possible that the 'this' pointer in the function call is somehow managing to recall GUIManager::CreateGUI()? perhaps i should try changing it from 'this' to 'GUIManager'... but ill try that tomorrow for now, im off to bed haha

This is unlikely. When you pass 'this' to the subscription method, you are just passing a pointer to the class (in otherwords, a pointer to GUIManager). CEGUI uses this pointer to call the supplied method, DisableCamera. If the 'this' pointer where getting corrupted, you would most likely get an exception when CEGUI actually tries to call GUIManager::DisableCamera; though it may theoretically be possible. Also, if the pointer to DisableCamera got corrupted, it could have changed to point to CreateGUI though that is also probably unlikely.

I'm not sure if this will help shed any light on the issue, but you may want to try adding this code right before creating CEGUI:


This will push out a lot more information to the CEGUI.log file. And again, I would recommend adding logging into your own code so you can see exactly what/when/how your code is executing.

I'v solved it..


calling GUIMananger::DisableCamera() was my mistake...
doing that recalls the GUIManager class constructor, and doing so recalls CreateGUI(); Im not sure how but the restriction that stops GUIManager from being started more then once failed. Faulty constructor code, my singleton's were not single, they were double.. fixing that fixed everything(i didn't code the constructor my partner did... lol... he couldn't stop laughing when i told him what he did wrong)

i should have been calling GUIManager::Instance()->DisableCamera()

what a stupid mistake i feel so stupid now... haha

Thanks for your advice Jamarr, the logging is what helped me find it(my logging not CEGUI's)

Glad you solved it.

Logging is a huge time/life saver when you have to debug a release build. Even a debug build if you are not getting any useful information out of the backtrace, which for some reason you where not. That should be pretty rare though; usually only happens if you've corrupted the heap.

Now, if I could just find the time to add logging into current the apps I've been working on this past year! lol

I agree that logging (or otherwise printing diagnostic messages somewhere) is a highly useful tool, in many instances even more useful than the debugger itself. Anyone who hasn't or doesn't do this when developing and debugging their software is surely missing out on a valuable source of information regarding the execution of their program(s)

I too have spent hours trying to track down an issue, only to solve it in 30 seconds after adding some code to print diagnostic output. And yes, I still sometimes fall into the mistake of not doing that from the start

CE.