[SOLVED] Crash on destroying bodies

[misho]

I have updated from the code from May, and now, when I dynamically remove a Newton body, I am getting an access violation on it. This is working in May build (I reverted back to it so I can continue work on my project)

Has anything changed with respect to how NewtonBody is removed/destroyed?

[JernejL]

Do you by any chance remove the bodies inside any of newton callbacks? That will cause a problem.

[misho]

Hi, thanks for responding!

Do you by any chance remove the bodies inside any of newton callbacks? That will cause a problem.

No - I don't do that. NewtonBody is simply a member of an "entity" object, in my case a spacecraft. I remove this entity by deleting whatever was dynamically allocated, and I also delete the body properly. Here is the code for the entity class destructor:

Code: Select all

TBEntity::~TBEntity(void)
{   
   DeleteAllObjectSFX();
   DestroyAllHinges();
   if(nBody)
   {
      NewtonDestroyBody(nBody);
      nBody = NULL;
   }
   if (planeCollision)
   {
      NewtonDestroyCollision(planeCollision);
      planeCollision = NULL;
   }
   delete OrbitSolver;
   if(bVerboseTBEntity) TB_PRINTF("TBEntity destructor: Deleting Entity\n");
}

This has worked flawlessly (and still does, in a build from May, which I now have to revert to until I find out what's going on).

The crash happens when I delete an entity, however, void ApplyForceAndTorqueCallback(const NewtonBody* body, dFloat timestep, int threadIndex) is still being called with invalid body pointer (not NULL).

Something changed in the Newton build between then and now that is causing this. I can fix it on my side no problem if it is something that was implemented differently - I just need to know what was changed, and how to fix what I have in place...

[Dave Gravel]

If you use VS in debug, The [frame stack] say some more infos about what is call before go at ApplyForceAndTorqueCallback ?
If you add a break point at the destroy body, Maybe you can see the frame stack difference from the working version.
If you say the last working version is from May, It is hard to find all changes.
Do you use listener or something similar ?
In the ApplyForceAndTorqueCallback do you use only direct command for newton body or you use a userdata ?

It look like something delete the body before the NewtonDestroyBody(nBody);
Maybe just set a breakpoint on the destroy to make sure it is really call.

[misho]

Thanks Dave,

I've tracked down the problem - it seems that now, for all the callback functions I declared, I have to explicitly set them to NULL in the destructor. So, for the destructor code I posted, inclusion of following functions:

Code: Select all

   NewtonBodySetDestructorCallback(nBody, NULL);
   NewtonBodySetForceAndTorqueCallback(nBody, NULL);
   NewtonBodySetTransformCallback(nBody, NULL);

fixed the issue completely. However - I'd still like to know what was the reason for such a drastic code change that resulted in aborted program execution without any warning? As I mentioned, previously this worked perfectly without the necessity of the code above.

[Julio Jerez]

I do not know what specific change cause your app to brake.
the change that I made was that I replaced the contact contain form a link list to a flat array.

the cause some problem when deleting objects because now contact can not be deleted on demand, instead the is a garbage collation pass the iterate over that contact array.

when a body is deleted now, they are connected for all system, bu the can no be deleted until the next update when all conceits are destructed.

the fact that you are still getting a callback of a delete body, maybe I forget to remove the body for the master list which is the one that do all the body updates.

I will check tonight.

[misho]

Thank you, Julio. Let me know if/when you fix it, I'd much rather have a fix on Newton side than on mine.

[Julio Jerez]

I did no do the check, let us do this this weekend.
I know I have few issues pending with you, so let us address that this weekend.
I will set up the repro test, and add all the stuff you are having problems with.

pin me of Friday in case I forget.

[misho]

No problem, will do!

Thanks,

[misho]

Hi Julio!

I forgot to remind you to have a look at this over the weekend - sorry! If you can take a look at it over the week, that would be great!

[misho]

Hi Julio!

Another reminder - Can you please take a look at this problem and check if, as you mentioned, it is something you changed in code that is causing it?

Thanks!

[Julio Jerez]

I've tracked down the problem - it seems that now, for all the callback functions I declared, I have to explicitly set them to NULL in the destructor. So, for the destructor code I posted, inclusion of following functions:

Code: Select all

   NewtonBodySetDestructorCallback(nBody, NULL);
   NewtonBodySetForceAndTorqueCallback(nBody, NULL);
   NewtonBodySetTransformCallback(nBody, NULL);

you may be right, the latest changes that place bodies on a list whe the are deleted, may case that a body get a callback after been logically dead.
I added this test so that all callback are reset at teh moment the body is deleted, the connection are destroyed after the update is completed.

Code: Select all

void dgDeadBodies::DestroyBody(dgBody* const body)
{
   dgScopeSpinLock lock(&m_lock);

   if (body->m_destructor) {
      body->m_destructor(*body);
   }
   body->SetDestructorCallback (NULL);
   body->SetMatrixUpdateCallback (NULL);
   body->SetExtForceAndTorqueCallback (NULL);
   Insert (body, body);
}


please sync and check again.

[misho]

Thank you!

I won't be able to check for a few days, as I am travelling, I'll report ASAP!

[JernejL]

Julio, i think this was not solved properly or a related regression occured in code.
For example - i get material callbacks called for destroyed bodies, because a object pointer is stored in the body userdata, this started causing crashes in all the material callbacks after a body gets deleted.

This is log from my app - from the latest newton compiled and built from trunk:

Debug Output: 'Newton body destroyed: 2738C5C0'
Debug Output: 'Newton body destroyed: DC3B2A0
Debug Output: 'Newton body destroyed: DC3B7E0'

Then when newtonupdate got called:

Debug Output: 'Material contact: bodies 2738CB00 193211A0 and userdata 2626A6BC 2411FCC'
Debug Output: 'Material contact: bodies 2738E7E0 193211A0 and userdata 2630FF3C 2411FCC'
Debug Output: 'Material contact: bodies 2738AE20 193211A0 and userdata 2629B41C 2411FCC'
Debug Output: 'Material contact: bodies 2738DAC0 193211A0 and userdata 2630EB04 2411FCC'
Debug Output: 'Material contact: bodies DC3B2A0 193211A0 and userdata 26421884 2411FCC'

[Julio Jerez]

ok I realized ther were no demo that call NewtonDestroyBody (visitor);
so I added one.
The boyancy demo now call dstropy body after they are in teh swimming pool for abopu 5 secund.
is this code here.

Code: Select all

               // test delete bodies inside trigger
               collisionMaterial.m_userParam[1] += 1.0;
               if (collisionMaterial.m_userParam[1] >= 60 * 10) {
                  NewtonDestroyBody (visitor);
               }
               NewtonCollisionSetMaterial (collision, &collisionMaterial);


if you sync and run the demo you will see bodies been delete if they are in teh pool for a while.
It seem to work as expected.

the material call back may be a possibility yes, but before I do anything again, I like to see it happening each one of these bug I try to make change with out real concrete test case.
what you say is possible, but I could not recreated it,
do you have a repro I can try?
this bug keep coming back again and again?