Jump to content
  • Advertisement
Sign in to follow this  


This topic is 2225 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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=#2E8B57][font=Monaco,]#define _HAS_ITERATOR_DEBUGGING 0[/font]
[color=#2E8B57][font=Monaco,]#undef _SECURE_SCL[/font]
[color=#2E8B57][font=Monaco,]#define _SECURE_SCL 0[/font]
[color=#2E8B57][font=Monaco,]#undef _SECURE_SCL_THROWS[/font]
[color=#2E8B57][font=Monaco,]#define _SECURE_SCL_THROWS 0[/font]

Share this post

Link to post
Share on other sites

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.


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:

> 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
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]

Code at the error point:

// <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 //

The specific MS std::map's code that's failing:

// <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

The CEGUI code that leads to that point:

// <CEGUIDefaultResourceProvider.cpp> Ln 150
if (String::npos == separators.find(directory[directory.length() - 1]))
d_resourceGroups[resourceGroup] = directory + '/';
d_resourceGroups[resourceGroup] = directory; // << This line

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.



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
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!