[perplexing] +9 bytes on heap obj. causes AABB assert crash
- nullsquared
- Old One
- Posts: 3245
- Joined: Tue Apr 24, 2007 8:23 pm
- Location: NY, NY, USA
- x 11
[perplexing] +9 bytes on heap obj. causes AABB assert crash
Ok, this issue is even more confusing than my shadow mapping issues from the past:
Apparently, I'm running out of stack space, or something. Adding 9 or more bytes to a class (which I always allocate on the heap, mind you) causes Ogre's AABB assert of minCorner <= maxCorner to trigger and kill my application.
Originally it started as an Ogre::Vector3, and I BARELY caught it down - I "randomly" decided to try 12 raw bytes (for the vector's 3 floats), and I got the same issue - that's how I "narrowed" it down.
This issue is really killing me, and I have absolutely no idea what to do here . It's happened before, but then I refactored my code (guess less variables?) and it disappeared. Now it's happening again. Good thing release mode still works fine, but worse off, when DEBUGGING WITH THE DEBUGGER, IT RUNS AS EXPECTED .
What the heck am I supposed to think here? This object is always allocated on the heap. I have 658 MB of free physical memory available. Why does debugging run fine (though debug mode on its own, not) as well as release mode? AND WHY AM I GETTING OGRE's AABB ASSERTS INSTEAD OF SOME KIND OF CRASH?
Ok, sorry, but this is _really_ weird. Ideas, ideas, please?!?
Ogre 1.4.6 (mingw SDK)
XP SP2
Code::Blocks (and obviously mingw toolbox)
Apparently, I'm running out of stack space, or something. Adding 9 or more bytes to a class (which I always allocate on the heap, mind you) causes Ogre's AABB assert of minCorner <= maxCorner to trigger and kill my application.
Originally it started as an Ogre::Vector3, and I BARELY caught it down - I "randomly" decided to try 12 raw bytes (for the vector's 3 floats), and I got the same issue - that's how I "narrowed" it down.
This issue is really killing me, and I have absolutely no idea what to do here . It's happened before, but then I refactored my code (guess less variables?) and it disappeared. Now it's happening again. Good thing release mode still works fine, but worse off, when DEBUGGING WITH THE DEBUGGER, IT RUNS AS EXPECTED .
What the heck am I supposed to think here? This object is always allocated on the heap. I have 658 MB of free physical memory available. Why does debugging run fine (though debug mode on its own, not) as well as release mode? AND WHY AM I GETTING OGRE's AABB ASSERTS INSTEAD OF SOME KIND OF CRASH?
Ok, sorry, but this is _really_ weird. Ideas, ideas, please?!?
Ogre 1.4.6 (mingw SDK)
XP SP2
Code::Blocks (and obviously mingw toolbox)
- Kencho
- OGRE Retired Moderator
- Posts: 4011
- Joined: Fri Sep 19, 2003 6:28 pm
- Location: Burgos, Spain
- x 2
- Contact:
Some code to look at? I have issues with segment sets' intersections in another project, and something in the back of my head tells me this might be related somehow. I've always considered these computations to be always as exact as possible, but these errors really keep me wondering if I've got lazy transistors in my micro or something
- nullsquared
- Old One
- Posts: 3245
- Joined: Tue Apr 24, 2007 8:23 pm
- Location: NY, NY, USA
- x 11
I honestly have no idea what kind of code to show youKencho wrote:Some code to look at? I have issues with segment sets' intersections in another project, and something in the back of my head tells me this might be related somehow. I've always considered these computations to be always as exact as possible, but these errors really keep me wondering if I've got lazy transistors in my micro or something
It happens completely randomly. Adding 1024 bytes to a derived class does not have the same issue
I gotta go now, more debugging later... if any ideas, PLEASE post... don't let this topic die
- pjcast
- OGRE Retired Team Member
- Posts: 2543
- Joined: Fri Oct 24, 2003 2:53 am
- Location: San Diego, Ca
- x 2
- Contact:
This is most assuredly a memory corruption issue.
a) Make sure all class variables are initialized to some default value. Try running program through memory debugger (ie valgrind)
b) Make sure you are not overflowing (writing past the end of arrays)
c) Allocating bytes correctly (if manually allocating any raw bytes) - i.e. correct size
d) Make sure you are not mixing Ogre builds (or other lib) - ie old versions with new headers, or debug/release libs (eg plugins), etc
e) make sure you are not double freeing, or reusing deleted pointers.
Try your same project under MSVC, maybe it will produce better debugging information.
a) Make sure all class variables are initialized to some default value. Try running program through memory debugger (ie valgrind)
b) Make sure you are not overflowing (writing past the end of arrays)
c) Allocating bytes correctly (if manually allocating any raw bytes) - i.e. correct size
d) Make sure you are not mixing Ogre builds (or other lib) - ie old versions with new headers, or debug/release libs (eg plugins), etc
e) make sure you are not double freeing, or reusing deleted pointers.
Try your same project under MSVC, maybe it will produce better debugging information.
Have a question about Input? Video? WGE? Come on over... http://www.wreckedgames.com/forum/
- nullsquared
- Old One
- Posts: 3245
- Joined: Tue Apr 24, 2007 8:23 pm
- Location: NY, NY, USA
- x 11
- nullsquared
- Old One
- Posts: 3245
- Joined: Tue Apr 24, 2007 8:23 pm
- Location: NY, NY, USA
- x 11
- eugen
- OGRE Expert User
- Posts: 1422
- Joined: Sat May 22, 2004 5:28 am
- Location: Bucharest
- x 8
- Contact:
i also get set extents debug assertions with the 1.6.7 version...i had those with 1.6.4 version also
here the error is related to the frustum attached to a shadow texture when rendering additive soft pcf shadows...i get it all the time in the same place and i have some weird nan values for bb corners for the root node (i cant reproduce it right now to give little more details but ill be doing in tomorow)
here i dont think there is any corrupting going on anyway, just an unusual case...
here the error is related to the frustum attached to a shadow texture when rendering additive soft pcf shadows...i get it all the time in the same place and i have some weird nan values for bb corners for the root node (i cant reproduce it right now to give little more details but ill be doing in tomorow)
here i dont think there is any corrupting going on anyway, just an unusual case...
- nullsquared
- Old One
- Posts: 3245
- Joined: Tue Apr 24, 2007 8:23 pm
- Location: NY, NY, USA
- x 11
Really, eh? Because my previous case of the same error was when I had PCF soft shadows, too - and another before that, in relation to my lighting, or so.eugen wrote:i also get set extents debug assertions with the 1.6.7 version...i had those with 1.6.4 version also
here the error is related to the frustum attached to a shadow texture when rendering additive soft pcf shadows...i get it all the time in the same place and i have some weird nan values for bb corners for the root node (i cant reproduce it right now to give little more details but ill be doing in tomorow)
here i dont think there is any corrupting going on anyway, just an unusual case...
Also, I'm getting this error both in HEAD (Shoggoth) and 1.4.7 (Eihort). I think I'll just edit the assert in there to something that simply "fixes" the min/max corners.
- novaumas
- Greenskin
- Posts: 107
- Joined: Mon Jan 21, 2008 9:44 am
- Location: Barcelona
- x 4
- Contact:
I think what pjcast said has lots of sense... I'd look along those lines.
Asserts are there so that your program crashes hard and you know something weird is going on
Although a temporary fix, I don't know if it's really a good idea, you'll only be hiding the real underlying issue.I think I'll just edit the assert in there to something that simply "fixes" the min/max corners
Asserts are there so that your program crashes hard and you know something weird is going on
- nullsquared
- Old One
- Posts: 3245
- Joined: Tue Apr 24, 2007 8:23 pm
- Location: NY, NY, USA
- x 11
I did look along those lines, and came up with ... not much.novaumas wrote:I think what pjcast said has lots of sense... I'd look along those lines.
Although a temporary fix, I don't know if it's really a good idea, you'll only be hiding the real underlying issue.I think I'll just edit the assert in there to something that simply "fixes" the min/max corners
Asserts are there so that your program crashes hard and you know something weird is going on
transformAffine() comes up with 1.#IND000 for the corners, which triggers the assert. Before the transform, the corners look alright. Release (no asserts) runs fine, each and every time - and, unless someone can come up with a solution, this "temp fix" will save me a lot of trouble .
- nullsquared
- Old One
- Posts: 3245
- Joined: Tue Apr 24, 2007 8:23 pm
- Location: NY, NY, USA
- x 11
Really odd: I stepped through everything in MSVC's debugger - and found out that the offending bounding box was my main camera's "merged" bounding box (updated on SceneManager::_updateSceneGraph()).
Immediately, I uncommented the line that attaches my camera to an Ogre node, excluding it from shoving it's bounding box down into the scene graph - guess what? No more assert!!!1!!!1!1111!one1!1!one1!!
It seems that the camera does not always give an AABB-happy bounding box, and causes the application to become FUBAR, when attached to a node - also, explaining why a camera is part of the problem for eugen, too!
Ideas?!
Immediately, I uncommented the line that attaches my camera to an Ogre node, excluding it from shoving it's bounding box down into the scene graph - guess what? No more assert!!!1!!!1!1111!one1!1!one1!!
It seems that the camera does not always give an AABB-happy bounding box, and causes the application to become FUBAR, when attached to a node - also, explaining why a camera is part of the problem for eugen, too!
Ideas?!
- eugen
- OGRE Expert User
- Posts: 1422
- Joined: Sat May 22, 2004 5:28 am
- Location: Bucharest
- x 8
- Contact:
The error here happens when updating the frustum of one of the camera attached to a viewport for a shadow texture
The error is raised in axisalignedbox::setExtents, the min and max values having qnan values for x and y, -10000 and 0 for z respectively. The parent method calling setextent is Frustum::_updatefrustumimpl, min and max values being calculated in calcProjectionParameters at the start of the method
The error is raised in axisalignedbox::setExtents, the min and max values having qnan values for x and y, -10000 and 0 for z respectively. The parent method calling setextent is Frustum::_updatefrustumimpl, min and max values being calculated in calcProjectionParameters at the start of the method
- syedhs
- Silver Sponsor
- Posts: 2703
- Joined: Mon Aug 29, 2005 3:24 pm
- Location: Kuala Lumpur, Malaysia
- x 51
There is a possibility you are running mismatched Ogremain.dll ie link to 1.4.7 but run with 1.4.6. I have got quite similar problem - what used to an innocent function calling trigger an ecxeption. Commenting out the offending line seem to solve it, but what really solves it is putting back the correct DLL.
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
- eugen
- OGRE Expert User
- Posts: 1422
- Joined: Sat May 22, 2004 5:28 am
- Location: Bucharest
- x 8
- Contact:
- nullsquared
- Old One
- Posts: 3245
- Joined: Tue Apr 24, 2007 8:23 pm
- Location: NY, NY, USA
- x 11
Ditto. Also, I tried three configurations (which, BTW, were a pain in the *): Code::Blocks SDK 1.4.6, VC++ HEAD from source, VC++ 1.4.7 from source. Each gave the exact same error (except HEAD had an amount of other errors due to the changes).eugen wrote:im quite sure the dll mixing case is not the thing here, we have a complex project configuration here and we make sure this never happens.
Mine occurs, as posted, in SceneNode::_updateBounds() when the camera submits its world bounding box, calling transformAffine() on mWorldBoundingBox (thus, calling setExtents() which triggers the assert).I believe somewhere there is a subtle bug; i will test it in detail in a few days or so