Painting crash

[Bird]

Hi Julio,

I'm hitting a hard to diagnose crash in Newton while painting using a phantom(Kinematic) body as in the sandbox Kinematic demo.

The crash happens as different places in Newton but it always seems to be in code relating to Contacts. Here's a video http://hurleyworks.com/media/flash/PaintCrash/PaintCrash.html

Feels like it might be a multi-threading issue to me. I create all my new bodies on Newton's thread in a NewtonListener callback but I make calls to NewtonBodySetMatrix, NewtonCollisionClosestPoint, NewtonWorldForEachBodyInAABBDo and NewtonCollisionIntersectionTest from LightWave's thread.

Is it safe to make those calls from another thread or do they have to be on Newton's thread too?

-Bird

[Julio Jerez]

NewtonBodySetMatrix Is the only one that may case problems
are you doing that concurrent with the update?

what it crash again see of any other thread is also working on the same broaphsope

[Bird]

NewtonBodySetMatrix Is the only one that may case problems
are you doing that concurrent with the update?

what it crash again see of any other thread is also working on the same broaphsope

Yes, I'm calling NewtonBodySetMatix to set the transform of the phantom body while the engine is updating. But I moved it into the NewtonListenerCallback so it's running on Newton's thread and there's still crashing.

I'm not very proficient at multi-threaded debugging. But I captured the vs2013 Parallel Stack map for 6 different crashes.http://hurleyworks.com/downloads/PaintCrash.zip ... maybe you can figure it what it means.

I did find a useful presentation from MS about debugging in vs2013. The multi-threading stuff is in the last quarter or so
http://events.visualstudio.com/eng/teched-north-america-2014/sessions-day-1/debugging-tips-and-tricks-in-visual-studio-2013/

Bird

[Bird]

I found it I hope. The main thread call stack at the time of a crash shows I was making calls to NewtonBodySetCollisionScale, NewtonBodySetMassProperties and NewtonBodySetForce at that time. I forgot that I had added a function so that users could rescale bodies while the simulation was running.

There's no more crashing if I stop making that call to update body properties. Do you think that was was the problem? Or did I just hide it again by changing the timing?

Once I learned a bit more how to use them, the vs 2013 Parallel Watch and Stack windows were incredibly helpful

-Bird

[Julio Jerez]

oh yes that function will definitely cause a guarantee crash if called for a newton update
The reason is that is destroy the contact joint explicitly,

Code: Select all

void NewtonBodySetCollisionScale (const NewtonBody* const bodyPtr, dFloat scaleX, dFloat scaleY, dFloat scaleZ)
{
///
   NewtonJoint* nextJoint;
   for (NewtonJoint* contactJoint = NewtonBodyGetFirstContactJoint(bodyPtr); contactJoint; contactJoint = nextJoint) {
      nextJoint = NewtonBodyGetNextContactJoint(bodyPtr, contactJoint);

// this is what cause the crash
      world->DestroyConstraint ((dgConstraint*)contactJoint);
   }
 

I have struggled to get to be re-entrant but is always a problem by adding a world->Sync(), because
but for that the semaphores have to use real mutexes with will make engine thread system several order of magnitude slower and prone to stuttering.

I made a change the make the function no destructive, instead of destroying the contact which is what causes the guarantee crash, I simple disable it.
Please try Sync and try again. That function should not crash the engine under any circumstances.

[Bird]

I made a change the make the function no destructive, instead of destroying the contact which is what causes the guarantee crash, I simple disable it.
Please try Sync and try again. That function should not crash the engine under any circumstance

Excellent! Works fine now.

Thanks very much!

-Bird