CEGUI (Crazy Eddie's GUI) Forums

throwing assert:

debug output:


callstack:


using ogre, open al, lua, cegui 0.7
vs2010, win 7, 32bit
is static build app..
working as dll...

the string "buf" (or "mem") in deconstruction (end of function) is the localy created one (file: CEGUIOgreResourceProvider.cpp :: line: 71)

i can also produce this error outside of cegui [use other lib first doing string stuff - so nearly every] (in an other lib - statically linked) - just by strings (with concat) like this (localy created and after method end deleted):

(not tested without concat)

any ideas?

edit:
log just shows initialisation is finished - this was the newest one...
and so it's not with every string - the strings in the log worked - as it looks...
example code also triggering this runtime error (inside of other lib):

(also triggering at local clean up, also calling destructor)
calling constructor (i think) three times - last time comes assert.

edit2:
type: std::basic_string<char,std::char_traits<char>,std::allocator<char> > * const

edit 3:
the last function call seams to return the false -> HeapValidate( _crtheap, 0, pHdr(pUserData) );

This is due to a heap conflict of some kind and is basically caused because something you linked to - which could be Ogre or it's dependencies - not being compiled with the same C/C++ runtime within MSVC++.

When you build a static version of CEGUI, by default it's built using the /MT and /MTd runtime options (to link against the static runtime), and you'll be (or should be) using the static dependency libs we provide for this config, which are also built with the /MT and /MTd setting. If you combine this in an app that is using the /MD and /MDd options, or with other libs that are using those options, you end up with the type of error you're getting.

In order to mitigate this "issue" somewhat, we provide an option in the config.lua to build a static version of CEGUI that uses the /MD and /MDd build option, and that should be used with the libs in the dependencies/lib/dynamic directory. Though that does mean that you will pick up some DLL dependencies.

So basically, you have to make sure everything is using the same C/C++ runtime setting. The cause of the issue could be the wrong setting in your project, linking to the wrong version of the CEGUI dependency libs, or linking to other components that use a different setting.

If you'd link to complain further about this whole C/C++ runtime debacle, please direct your browser to http://www.microsoft.com

CE.

hi,
i think i understand the problem only half.

i have at the moment the following libs in the project:

*self compiled (boost only the 100-mt-sgd part of thread and date time)
#must be dll because of lgpl license

i want to compile as much as possible static (so all beside the sound lgpl stuff it seams. i still use ogre as dll at the moment)
(ogre sdk for vs2010, cegui dependencys 0.7.x r3 vs2010)

so i use the MD stuff in the audio part's (only self compiled is -> ogreAL).
for all the others i use MT.
app compiles and links fine with MT but with MD i get linker errors for "allready defined <other runetime lib stuff> in <cegui stuff>"

if i got you right i have to use the same option in every lib (and every dependency should have used the same).
but than it's not possible to link against some static and some dll libs at the same time - is that right?
i thought dll's would drop such boundaries.

so after it seams i'm using right depends and there are not much left i don't compile by my own (or found in cegui/ogre precompiled stuff for vs2010).
i realy don't know how to solve this problem and sadly i don't get your explanation.
if i got you rigth it must be one of the sound libs or the ogre itself because i try to use them as dll??

edit:
if i would change the static builds to MD, i have to switch depends to dynamic rigth?
this would mean i must provide the dll's of the depends - with exe right?
is there a way to realy include as much as possible in static way and just use some libs as dynamic?

You are confusing two different compiler options. I do not know why so many people have trouble with this. Basically, you are confusing a compiler options to "compile a DLL" with a compiler option to "link to a DLL". I can only assume this confusion is because people fail to read the documentation and just assume their meaning!

1) configuration type: this option tells the compiler what type of library you are building. In other words, this option determines if you build an executable, a DLL, or a static library.

2) runtime library: this option tells the compiler what type of Microsoft Visual C Runtime library you are linking to. This option tells the compiler what type of Microsoft Visual C Runtime library you are linking to. /MT = link to static version, /MD = link to dll version.

So, in essence, the runtime library only determines what MSVCR library you link to. It does not mean your project will be compiled as a DLL; that is what the configuration type determines. So you can build a DLL that links against the static version of the MSVCR library. The LGPL explicitly allows static linking of system libraries.

As CE already pointed out, the heap errors occur because you have different libraries linking to different versions of the same MSVCR symbols. So when you see a compiler warning that says "<symbol> already defined in <another library>" you should not simply dismiss it! It is telling you that if you decide to ignore these warnings something bad might happen.

And to follow up: It's almost certainly because you're linking the /MT compiled CEGUI parts with the /MD compiled Ogre parts. Unless you want to recompile a whole load of dependencies yourself, the CEGUI setting, "STATIC_BUILD_WITH_DYNAMIC_DEPS" set to 'true' and a rebuild of CEGUI should solve the issue, though you will pick up a SILLY.dll dependency, and you need to then link to the libs in the dynamic subdir and not the static subdir.

CE.

very thx for the good explanation.
now the problem is clear.