Stack around the variable 'input' was corrupted.

[Chemtek]

I've compiled Ogre and CEGUI against the same source release, and the program compiles without any problems.

Instead, when I run it, I get that message in the title. Logs don't seem to be of any use, instead just cutting off where they reached.
Checking out the break, it shows contents of the XML file, so I can only assume they have infact been read.

Has anyone else managed to deal with this, or at least encountered it?

Much thanks for any help


Ogre.log: http://pastebin.com/YzsNMyuK

CEGUI.log: http://pastebin.com/ZTMjR26k

Code listing: http://pastebin.com/05bEYqhH

Crash Details: http://pastebin.com/keEndL0h

In relation tot he code listing, I could post the whole source code if necessary, however the program doesn't make it any further than the commented line in Initialize.cpp, and thus what you see there is literally all the code that runs.
Without the Initialize_CEGUI() function, the program operates as expected (a black screen, but still :p)
the exact line causing the error is:
CEGUI::System::getSingleton().setDefaultMouseCursor( "TaharezLook", "MouseArrow" );


I'm pretty confused by this, and I guess I've just overlooked something immensely important, but after 2 days I can't figure out what that is

[CrazyEddie]

This should work fine. I'm not sure wtf is going on, so I'll take a couple of wild stabs at it!

* It might happen if the Ogre headers used to compile CEGUI are different to the ones for the version of Ogre in use (though you already said these were the same).
* It could happen if the struct alignment rules in use are different between parts of the compiled code.
* It could be random memory corruption from elsewhere that just happens to manifest at that location.

Could you post a full debug callstack from the point of the error/assertion?

CE.

[Chemtek]

Thanks for the reply
This is what I get from VS2010:

Callstack window: http://pastebin.com/zxh87rQV

Output window: http://pastebin.com/ALTzDxWt

For what it might be worth,
I'm using VS2010 (C++) express, Windows 7 Professional 64bit

[Chemtek]

For reasons unknown to me, the error position has changed since I viewed the call stack, but the message hasn't.

It now happens in CEGUIExpatParser.cpp, Line 66
CEGUI::System::getSingleton().getResourceProvider()->loadRawDataContainer(filename, rawXMLData, resourceGroup);

Unsure if it's the problem, but resourceGroup variable claims a bad pointer:

http://pastebin.com/HsuZu64q

[Chemtek]

Well, after a whole day and a half of compiling, recompiling, wiping, downloading SDKs, downloading source releases, downloading SVNs, compiling, cross compiling, and debugging, I think I've finally worked out what the problem is - God hates me, and is punishing me for something I don't remember doing.

I've decided for the time being to revert back to 1.6.5 where everything works as intended :p
I'll try and get the newly seperated Ogre/CEGUI libraries to work together a few versions down the road when I at least have some semblance of a usable product to worry about, right now I think I'll spare myself the headache, since I'm pretty sure this is a problem with my system configuration somehow rather than naughty code somewhere.

[CrazyEddie]

The moving error location is definitely indicative of memory corruption, though I still can't explain how/why that's the case. In a few days (or so) I'll try to run some tests using MSVC++ 2010 to make sure that everything works as it should - just in case there's something messed up that I'd not realised.

CE.

[Chemtek]

Under VS2008 I get the exact same line giving me a very similar error:
Unhandled exception at 0x7575b727 in BADNESS.exe: Microsoft C++ exception: CEGUI::GenericException at memory location 0x003fc700..

It won't let me run debug into it though unless i want to wade through assembler, but there's some scary gypsy magic in my call stack: http://pastebin.com/ZkE007FU

Since I haven't encountered this problem anywhere else, I just have a sneaking suspicion that I'm either doing something wrong at the compilation stage which I'll need to work out, or my external computer setup itself is the problem, being win7x64

[Jamarr]

The standard windows "unhandled exception" message only tells you the type of exception, it does not include any details from the exception object; since you appear to be getting a CEGUI exception, then the exception message should be in your CEGUI.log file. Alternatively (and you should be doing this anyway) you can try/catch the exception and read/display the error message when it occurs. It still sounds like a memory corruption issue (eg you are overwriting memory somewhere), but in any case the exception-message should provide insight into why it is being thrown.

[baiyunping333]

I have the same question, my external computer setup itself is winxpx32,visual studio2008. How can I do with it.

I'm looking forward to see that someone can find the cause.I spend a whole day,but I can't find it.

[king387779]

I have the same question, my external computer setup itself is winxpx32,visual studio2008. How can I do with it.

I'm looking forward to see that someone can find the cause.I spend a whole day,but I can't find it.

Run-Time Check Failure #2 - Stack around the variable 'xxx' was corrupted.
Cause
Stack pointer corruption is caused writing outside the allocated buffer in stack memeory.
Solution
This kind of error is detected by setting /RTC1 compiler option from menu Project -> Settings -> Configuration properties -> Build -> Compiler -> Compiler flags when using TDP cvisual7 in IBM® Rational® Test RealTime environment.. This enables stack frame run-time error checking. For example, the following code may cause the above error messge.

[Sigma]

I encountered this error and thought I'd post my fix. Hopefully it will save someone else a bit of pain.

For me, it occurred because I had built CEGUI with stl debug iterators turned off (for debug builds), but I had built Ogre and my Application with them turned on. Thus any call that passes an stl class (such as string) into CEGUI would eventually trigger a stack corruption error.

Either rebuild all your sources with iterator debugging turned off, or rebuild CEGUI with it turned on.

Search for _HAS_ITERATOR_DEBUGGING and _SECURE_SCL in your project settings under C/C++, Preprocessor, Definitions. Also double check if you have it #defined somewhere in your own application.

This worked for me, but if it doesn't work for you then you probably should double check other compiler setting differences between CEGUI and your Application.