CEGUI (Crazy Eddie's GUI) Forums

Okay,

I just switched to VS 2005 Express, and now I am having a problem with the following code:



When it executes, i get the error:


When it gets to:


Although there are no errors shown, here is my ceGUI.log


This only happens when I compile to my debug version. My release works just fine, and evn handles the events correctly. I have tried linking my debug with both debug and release versions of all ceGUI DLLs, but it does not make a difference.

Any ideas?

A backtrace might shed some light on this.

Your log seems to be CEGUI v0.3... Why not upgrade?

I will try upgrading and see if it helps. I hadn't wanted to as I was afraid that something might break, but since it's broke already

Okay, I updated to 0.4.1, but the problem is still there. Also, by backtrace, do you mean the call stack? Before updating to 0.4.1, I remember CEGUI stuff being listed in the call stack, but not after updating, which was odd. After the update, the last thing in my call stack was my own code.

Here is my new CEGUI.log:

Okay, the problem may not have been with CEGUI. It is now fixed, but I can't explain exactly what I did. I had messed around with some libraries being included and changed some of the pre-compilation defines, and it now works.

Thanks, lindquist, for all of your help. It is appreciated.

Yes, I have the same problem : the "subscribeEvent" crashs when CeGUI is compiled in Release mode and the executable is compiled in debug mode.

[EDIT] I use the last version of CeGUI, of course.
[EDIT] And obviously, I disabled CEGUI_LOAD_MODULE_APPEND_SUFFIX_FOR_DEBUG in CeGUIconfig.h


Do you have an idea ?

Thanks.

Pacôme

I insist with this bug which is very penalizing for us.

I explain a little bit more : we give CeGUI in our SDK (http://www.ease-production.com) and we only give release-binaries. And then, if ALL the users must CeGUI in release-mode because we don't give the debug version, it means CeGUI won't be acceptable at all for game development.

The problem is:
- When CeGUI's DLLs are compiled in Release mode
- When an application which use these CeGUI Dlls is compiled in Debug mode
=> the application crash on the first "subscribeEvent" call.
It's exactly the same problem exposed by Viper.

You can test it by yourself:
1) Download EaseWrapperSDK on www.ease-production.com (you need to have DirectXSDK installed)
2) Try to compile Tutorial 23 : it works fine in debug and release modes, because it uses CeGUI via our interface, and it uses only LUA construction
3) Try to compile Tutorial 24 : it crash in Debug mode on the first "subscribeEvent" call. But it works in release mode.

I've tested it again this week-end, with several CeGUI configuratons, but the problem didn't disappear.

I'm really sorry, but I don't have the time to read all CeGUI source code to understand where the problem comes from, and it's a pity to not include CeGUI in the next release of our SDK just for this bug......

I hope someone will help us.

Best regards,

Pacôme

I insist with this bug which is very penalizing for us.

I explain a little bit more : we give CeGUI in our SDK (http://www.ease-production.com) and we only give release-binaries. And then, if ALL the users must CeGUI in release-mode because we don't give the debug version, it means CeGUI won't be acceptable at all for game development.

The problem is:
- When CeGUI's DLLs are compiled in Release mode
- When an application which use these CeGUI Dlls is compiled in Debug mode
=> the application crash on the first "subscribeEvent" call.
It's exactly the same problem exposed by Viper.

You can test it by yourself:
1) Download EaseWrapperSDK on www.ease-production.com (you need to have DirectXSDK installed)
2) Try to compile Tutorial 23 : it works fine in debug and release modes, because it uses CeGUI via our interface, and it uses only LUA construction
3) Try to compile Tutorial 24 : it crash in Debug mode on the first "subscribeEvent" call. But it works in release mode.

I've tested it again this week-end, with several CeGUI configuratons, but the problem didn't disappear.

I'm really sorry, but I don't have the time to read all CeGUI source code to understand where the problem comes from, and it's a pity to not include CeGUI in the next release of our SDK just for this bug......

I hope someone will help us.

Best regards,

Pacôme

I do have access to a windows visual c++ development workstation. so it's very hard for me to say where this is coming from.

The event/callback system in CEGUI makes heavy use of c++ templates. You're not saying which VC++ version you have. There are stlport builds available for vc2002. I have no idea if it would help...

Also the downloadable cegui 0.4.1 sdk installer comes with both release and debug libraries. If you could post the call-stack at the point of the crash it would be useful to pinpoint the problem.

Also does it crash if you link the debug build to the debug library? (you said the other sample used only lua?)

HTH

It doesn't depend on the version of Visual Studio : we've tested with VS2003 and VS2005, the result is the same.

The results are:
- EXE-Debug + DLL-Debug => OK
- EXE-Release + DLL-Release => OK
- EXE-Debug + DLL-Release => Crash on subscribeEvent.

We can't access the call stack because CeGUI is in release mode. And even if we produce a pdb file with debug information, it just crash on the "subscribeEvent" call. It's very strange.

If you have a starting point of idea, it would be great.

I will make a small example based on your dll.

Regards,

Pacôme

I meant to write that I do not have access to visual studio.
I dunno what it is. I think the templates are complaining. But I really dont know. You'll need to get some kind of information of where inside subscribeEvent it's going wrong. cant you make a program database even though you're in release mode?

Pacome wrote:
It doesn't depend on the version of Visual Studio : we've tested with VS2003 and VS2005, the result is the same.

The results are:
- EXE-Debug + DLL-Debug => OK
- EXE-Release + DLL-Release => OK
- EXE-Debug + DLL-Release => Crash on subscribeEvent.

You can't mix release and debug mode DLLs. The reason for this involves use of new/delete operators across module boundaries. When all parts use the same debug/release mode they all share the same heap (that of the C++ runtime dll), when you mix and match, some parts will use the release C++ runtime and others will use the debug C++ runtime - if this results in memory allocated on one heap being released on another, then you will get the kind of trouble you are seeing.

So, in short, always make sure that all of your exe and dll modules are linked to the same runtime (most easily achieved by not mixing release and debug components)

CE.

Then, it means the solution is quite easy to get : overriding new/delete/malloc/free operators in order to let all memory management being done in the same heap.

I had this problem long time ago, and it could be solved very easily.

In EaseCore (which is opensource and downloadable at www.ease-production.com), there is a class called "CAllocateable". The new/delete/malloc/free operators have been overriden for this class, and they're called inside EaseCore even if you create an instance of CAllocateable in another library.
All the classes used in EaseTools are derived from CAllocateable, and then you are sure that you can create or delete all your instances where you want.

The two files are:
- Allocator.h
- Allocator.cpp
in EaseCore (you can get in EaseWrapperSDK).

It could be a good idea to make it safe.

Best regards,

Pacôme