UpdateCollision crash
by Howard Dortch · in Torque Game Engine · 09/23/2005 (1:09 pm) · 8 replies
When I delete a vehicle or rigidshape object from script using %obj.delete() and the object is inflight soon to collide with somehting I get a crash here
bool RigidShape::updateCollision(F32 dt)
{
MatrixF mat,cmat;
mConvex.transform = &mat;
mRigid.getTransform(&mat);
cmat = mConvex.getTransform(); <<<<< crash here because mConvex is invalid
... blah
}
seems the object doesnt get deleted but mConvex does. How can I test for mConvex to be valid or how can I guarantee this function doesn't get called if I delete it?
bool RigidShape::updateCollision(F32 dt)
{
MatrixF mat,cmat;
mConvex.transform = &mat;
mRigid.getTransform(&mat);
cmat = mConvex.getTransform(); <<<<< crash here because mConvex is invalid
... blah
}
seems the object doesnt get deleted but mConvex does. How can I test for mConvex to be valid or how can I guarantee this function doesn't get called if I delete it?
#2
09/24/2005 (8:02 am)
That seemed to work but I had to use 100ms delay. Someone there should really look in to the destructor for those functions. It would appear that members of an object are getting deleted before the object itself, bad JUJU IMHO
#3
ProcessList::advanceObjects
::processTick
::updatePos
::updateCollision
Try adding a
plUnlink();
as the first line in the ::onRemove()
It should get called further down in the Parent::onRemove chain but calling it twice won't hurt anything.
That will remove it from the process list and hopefully fix the problem.
-Jerry
09/24/2005 (9:22 am)
If you walk the stack trace I think you'll find something like this:ProcessList::advanceObjects
::processTick
::updatePos
::updateCollision
Try adding a
plUnlink();
as the first line in the ::onRemove()
It should get called further down in the Parent::onRemove chain but calling it twice won't hurt anything.
That will remove it from the process list and hopefully fix the problem.
-Jerry
#4
If you schedule the deletion with a zero millisecond delay, what that will do is to cause the deletion to happen on the very next tick cycle, which allows the rest of the previous cycle to finish up. Try the schedule, it should clear up all of your issues. Doing what Jerry said could be quite dangerous since it is going outside the normal operations of the simulation, and could have a lot of unexpected issues.
09/24/2005 (9:44 am)
As Matt says, the problem is that you are forcing the deletion to occur during the current processTick of the simulation, but the simulation itself isn't actually done with the object.If you schedule the deletion with a zero millisecond delay, what that will do is to cause the deletion to happen on the very next tick cycle, which allows the rest of the previous cycle to finish up. Try the schedule, it should clear up all of your issues. Doing what Jerry said could be quite dangerous since it is going outside the normal operations of the simulation, and could have a lot of unexpected issues.
#5
09/24/2005 (11:07 am)
Actually, IIRC schedule runs off of the main event loop, not the tick loop. So deletion would happen the very next frame. Some quick experiments should establish this. Naturally deletion will take some time to propagate over the network.
#6
09/24/2005 (11:37 am)
Good point Ben, I abstracted more than I should have: as Ben said, it's the next main event loop, but what is important to keep in mind is that it is a safe way to say "I need this object deleted as soon as it makes sense to do so".
#7
09/26/2005 (6:44 am)
The schedule 0,0 doesn't solve the problem, still crashes. I have to bump that value up some like 10 or 20 and it seems to be more stable. gota love fudge factors. Thanks for the help at least now I know why and how.
#8
Incidentally, the line mConvex.foo() can't die from a bad pointer value for mConvex - no dereference occurs.
10/02/2005 (11:01 pm)
Any non-zero value should make it happen "next" - if the value has to be a particular non-zero value that suggests deeper problems in your code.Incidentally, the line mConvex.foo() can't die from a bad pointer value for mConvex - no dereference occurs.
Associate Matt Fairfax
PopCap