Execution error D3DX debug but not retail

Started by
8 comments, last by bobbinus 18 years, 7 months ago
Hello Got a weird problem that i got im not sure how to approach. My game crashes in the debug mode but not retail. I have experienced this before but changed my code to avoid the prblem although im not particularly keen to do so if there is another way about this. It is do with the D3DXVector3 struct. At one point in a member function of a major class i have there is some operations to do with the D3DXVector3 using local variables(initialised from members of the class). For some unknown reason a subtraction operation of two of the local variables results in the change of an unrelated member struct of the major class mentioned. This struct has some pointers to the kind of objects being used in the aforementioned function and one of them gets corrupted. However as i step through this function none of the objects being referenced related to the one that was pointed to at the time of corruption. The corruption reluts in a crash but none of this occurs if i build in retail mode, but i need debug too.... Hope this isnt too confusing and thanks a lot for any insights.
Advertisement
Have you tried doing a clean rebuild? Can we see the relevant code? It sounds like some kind of buffer overrun or something.
Yes i have tried clean rebuild. I thought that would fix this when i saw the error but it hasnt....

This is the code of the function. In the second last line where vDist is calculated another member is corrupted. It actually occurs during the 'operator' defined minus function for D3DXVec3:

void PhysicsEngine::CheckBallWallCollision( MovingObject* pMovObj,
int iWallRef )
{
float fDist, fVel, fVelTolerance;
D3DXVECTOR3 vDist, vContactPt, vRel, vTangent, vWorldAngVel;

if( iWallRef==4 )
fVelTolerance = BALLFLOOR_VEL_TOL;
else
fVelTolerance = 0.0f;

//check if close enough for a collision
vDist = pMovObj->GetPos() - m_WorldBox.walls[iWallRef].dist;
fDist = D3DXVec3Dot( &vDist, &m_WorldBox.walls[iWallRef].normal );
Is iWallRef definitely valid? Are you sure you're not off-by-one (I.e. accessing m_WorldBox.walls[6] when you only declare an array with 6 walls)? I had that error recently, and it caused the exact same behaviour you have.

Failing that, it might be worthwhile trying to step into the dissasembly (Ugh) to see what address is accessed and why.
urggghh indeed. I dont know how to read disassembly effectivly....

99% sure that the wall ref thing is fine. I am sure that the 2 formal paramters are valid because i can check the memory addresses of the objects that are being referenced as a cross check amd its the same for both.
The program will use a different heap, depending on if it is compiled in debug or retail. So clobbering memory in one will not necessarily act the same in the other.

xyzzy
Actually, that's a good situation because you can use the debugger to find the problem. It really sucks when it crashes in release but not in debug.

Here are reasons that it would crash in that line:
  1. The value of pMovObj is invalid.
  2. The value of this is invalid.
  3. The value of iWallRef is invalid.
  4. It is really crashing in GetPos().

What does the debugger say?
John BoltonLocomotive Games (THQ)Current Project: Destroy All Humans (Wii). IN STORES NOW!
Using "Good situation" frightens me a little John ;p.. hehehe

John it actually doesnt crash on that line. That line for some unknown reason invokes a corruption of another member of PhysicsEngine(pointer address). That corruption causes a crash further down the track(in a different member function of PhysicsEngine) when it is accessed.

The other member is an array as shown below(snippet from PhysicsEngine class definition):

struct COLLISION
{
Object* pObject1;
Object* pObject2;
COLL_TYPE CT_CollType;
D3DXVECTOR3 vNormal;
D3DXVECTOR3 vVelRel;
};

class PhysicsEngine
{
//****///

private:
COLLISION m_Collisions[MAXCOLLISIONS];
int m_NumCollisions;
//****///
};

At the time of the infamous line being executed m_NumCollisions=1. In other words, my engine has made one collision struct. The two objects involved in that collision are pointed to by that struct. At the time of the corruption,
m_Collisions[0].pObject1 is pointing to the same address as the pMovObj formal parameter. However, it is m_Collisions[0].pObject2 that become corrupt during this line of code and it is apparently unrelated to to anything here.
hmm..this is getting absurd now. I found another object in my game that causes a similar error. The same corruption of the Collision struct array in the same member function but on a different line. This time on the 2nd line when I declare local D3DXVECTOR3 variables - and am not even initialising them!!

I know that 99.9% of the time when u suspect its a hardware/environment bug its not and you find its somthing you did eventually. This time i cant. Can anyone suggest how i can debug at a lower level here?
Yep...found it...eventually....sorry for the trouble and thanks again for the great support. Once again bobbinus error strikes.

Was to do with the a completly seperate piece of code that treated the offending game objects. I was setting pointers to point to local copies i had made of them(instead of referencing them directly by address). So i am assuming that it was just chance that this piece of memory was overwritten by that function thereby 'corrupting the data'. Weird thing is this is one of the older parts of my code and has never given trouble(hence my bewilderment) but was obviously a disaster waiting to happen, just lying dormant.

Love B

This topic is closed to new replies.

Advertisement