Sign in to follow this  
Firestryke31

MSVCRT woes

Recommended Posts

Hi all;

I'm having problems with the debug MSVCRT. I'm using Ogre and CEGUI, compiled manually along with all of their support libraries. Most of them were downloaded either yesterday or the day before, or at least checked to see if they're the latest versions (Ogre's at 1.7.4 and is the only "outdated" library I've had to compile myself). Ogre works fine so far. My problem right now is with CEGUI, or rather the std::map that CEGUI is trying to use.

As far as I know, every library that I've custom compiled is using the same version of the CRT. I specifically went through and made sure of it. They're all using the multithreaded debug dll version. However, CEGUI crashes the first time it tries to use one of it's std::maps. And it is std::map that's crashing, as it seems that it's trying to use the uninitialized 'this->_Myhead' on line 1743 in VS2010's 'xtree' header (Access violation reading location 0xabababaf).

I've gone through and ensured that everything is using the same CRT, and rebuilt everything from scratch, from libraries that aren't being used yet to my .exe, and yet I still get the access violation.

I'm not using Ogre's resource system yet, and I'm only very loosely following the tutorials (there are things I don't like about the way they do things, and there are things in the tutorials I don't need or want in my game). The one thing I found that's relevant to my case was posted on the CEGUI forums, and his solution was "Ogre does it for me. That's what I get for not reading the tutorials and only copy/pasting code." which doesn't help me.

Why would not using Ogre's resource system with CEGUI cause std::map to crash? What can I do to stop this odd behavior?

Share this post


Link to post
Share on other sites
Check for any of these in their sources or in your sources. They change the layout of the data.


[color=#2E8B57][font=Monaco,]#undef _HAS_ITERATOR_DEBUGGING[/font][/color]
[color=#2E8B57][font=Monaco,]#define _HAS_ITERATOR_DEBUGGING 0[/font][/color]
[color=#2E8B57][font=Monaco,]#undef _SECURE_SCL[/font][/color]
[color=#2E8B57][font=Monaco,]#define _SECURE_SCL 0[/font][/color]
[color=#2E8B57][font=Monaco,]#undef _SECURE_SCL_THROWS[/font][/color]
[color=#2E8B57][font=Monaco,]#define _SECURE_SCL_THROWS 0[/font][/color]

Share this post


Link to post
Share on other sites
Hi

What version of CEGUI are you using? 0.7.6? And for the dependencies are you using the prebuilt MSVC 2010 dependecy pack? Or did you compile our source based dependency pack intended only for the 1.0 release? Or did you obtain the individual libs seperately and compile those? If you did compile yourself, what configurations did you use?

What configuration of CEGUI are you linking? As in, static or dynamic. And what, if any, options did you set when building CEGUI?

Are you certain that you're linking only debug libs to the debug configuration of your project and only release libs to the release configuration? Does the same issue arise in both debug and release configurations?

If the issue occurs in the debugging build, can you post a callstack with debugging symbols from the point of the error? Is there a CEGUI.log file you could post? Posting some code might be informative too.

CE.

Share this post


Link to post
Share on other sites
CEGUI is version 0.7.6. I have compiled everything from individually downloaded libraries, using the default configurations where possible (at most renaming final outputs so I don't have to copy/paste the files 5 times). I am using the debug builds and I have not yet built any release builds.

I am using DLLs for as many libraries as support it to reduce code duplication.

The CEGUI log ends at "---- CEGUI System initialisation completed ----" with an apparent attempt to write another line that's truncated after the timestamp.

Call stack:
[CODE]
> CEGUIBase_d.dll!std::_Tree<std::_Tmap_traits<CEGUI::String,CEGUI::String,CEGUI::String::FastLessCompare,std::allocator<std::pair<CEGUI::String const ,CEGUI::String> >,0> >::_Lbound(const CEGUI::String & _Keyval) Line 1742 + 0x8 bytes C++
CEGUIBase_d.dll!std::_Tree<std::_Tmap_traits<CEGUI::String,CEGUI::String,CEGUI::String::FastLessCompare,std::allocator<std::pair<CEGUI::String const ,CEGUI::String> >,0> >::lower_bound(const CEGUI::String & _Keyval) Line 1450 + 0x10 bytes C++
CEGUIBase_d.dll!std::map<CEGUI::String,CEGUI::String,CEGUI::String::FastLessCompare,std::allocator<std::pair<CEGUI::String const ,CEGUI::String> > >::operator[](const CEGUI::String & _Keyval) Line 211 + 0x10 bytes C++
CEGUIBase_d.dll!CEGUI::DefaultResourceProvider::setResourceGroupDirectory(const CEGUI::String & resourceGroup, const CEGUI::String & directory) Line 153 + 0x16 bytes C++
Game.exe!Core::Core() Line 98 + 0x5a bytes C++
Game.exe!WinMain(HINSTANCE__ * hInst, HINSTANCE__ * __formal, char * strCmdLine, HINSTANCE__ * __formal) Line 28 + 0x34 bytes C++
Game.exe!__tmainCRTStartup() Line 547 + 0x2c bytes C
Game.exe!WinMainCRTStartup() Line 371 C
kernel32.dll!7506339a()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!777a9ef2()
ntdll.dll!777a9ec5()
[/CODE]

Code at the error point:
[CODE]
// <My Code>
guiRenderer = &CEGUI::OgreRenderer::bootstrapSystem(*renderer);
gui = CEGUI::System::getSingletonPtr();
CEGUI::DefaultResourceProvider *rp = (CEGUI::DefaultResourceProvider*) gui->getResourceProvider();

// Get the resources directory from my config file loaded earlier, with a default of './GUI/'
Ogre::String uiResources = config->getSetting("Resources", "GUI", "./GUI/");

rp->setResourceGroupDirectory("gui", uiResources); // << Point of Failure //
[/CODE]

The specific MS std::map's code that's failing:
[CODE]
// <xtree> Ln 1740
_Nodeptr _Lbound(const key_type& _Keyval)
{ // find leftmost node not less than _Keyval
_Nodeptr _Pnode = _Root();
_Nodeptr _Wherenode = this->_Myhead; // end() if search fails
// ^^ That line
[/CODE]

The CEGUI code that leads to that point:
[CODE]
// <CEGUIDefaultResourceProvider.cpp> Ln 150
if (String::npos == separators.find(directory[directory.length() - 1]))
d_resourceGroups[resourceGroup] = directory + '/';
else
d_resourceGroups[resourceGroup] = directory; // << This line
[/CODE]

The most confusing part is that it's the std::map that's failing, almost as though it's not being initialized properly somewhere.

Share this post


Link to post
Share on other sites
The issue here is that you are correctly using the CEGUI::OgreRenderer::bootstrapSystem call, which initialises all the required objects for CEGUI to interface with Ogre - and this includes the CEGUI::OgreResourceProvider. Later in the code you get a pointer to that object and cast it to CEGUI::DefaultResourceProvider which is an incompatible type (using C++ dynamic_cast there would alert you to an issue, since you could test the cast pointer for 0).

When using the CEGUI::OgreResourceProvider you do not need calls like DefaultResourceProvider::setResourceGroupDirectory, since that basically is already taken care of by way of either hard coded Ogre resource set up or by using a resources.cfg file. You should therefore skip the setResourceGroupDirectory call and just set the default resource group or groups.

HTH

CE

Share this post


Link to post
Share on other sites
I don't use the Ogre resources.cfg file (I hate having 4 different config files that control only different aspects of the same software), so I'll have to look in to how to tell CEGUI to use the resource directory I have in my unified config file as opposed to whatever Ogre is trying to use.

Thank you for your help!

Edit: Not nearly as drastic a chance as I feared, now I just have to figure out why FreeImage doesn't want to load in VS2010 so I can build it so I can rebuild Ogre with it so I can actually load images. Then once my game works on Windows I get to do all the building again for Linux and Mac and maybe iOS. Edited by Firestryke31

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this