Skeleton crash only in release mode

[JoeJ]

newton-crash.jpg (238.26 KiB) Viewed 6478 times

I get one of two crashes in release mode if i do the physics update. (Will post second image in a second post.) Setting up the scene works fine.

In debug mode everything works, including the simulation. The joints work. I can play back a walking animation with the ragdoll and all looks good.

The joints are custom. If i set them to m_jointIterativeSoft, no crash and it works in release mode too. That's the only hint i have. Maybe you have some idea.

Btw, i noticed the issue while i was still on my old version of Newton. Maybe a year old.
Then i did the update yesterday, but still the same two crashes on the same spots, with the exact name value for the 'accel' read access violation.

Edit: Tried Clang compiler as well. Behavior remains the exact same. Same two crashes with the same values.

[JoeJ]

newton-crash2.jpg (122.17 KiB) Viewed 6477 times

The second kind of crash. It feels random which one i get.

Maybe i forgot something with the joint or when setting up the ndModel, but i have no clue.

[JoeJ]

newton-crash3.jpg (72.36 KiB) Viewed 6477 times

Another image just to show the scene.
There are static bodies for the floor, and the ragdoll ndModel, but nothing else in the scene.

Btw, i'm very confused about the new smart pointers (which i've never used before).
Here is an example of how i use them:

Code: Select all

   template <class T>
   void AddJoint (ndWorld* world, T* joint)
   {
      ndSharedPtr<ndJointBilateralConstraint> ptr(joint);
      world->AddJoint(ptr);
   }


Its a helper function. I still use just regular pointers everywhere, but when i add a body, joint, or model, i create a smart pointer as shown above just temporarily, only so i can add the stuff.
Now i wonder about two things:
Why do i have to use smart pointers, although i have no intend to get any advantage from it?
Is the above practice valid at all? I'd be worried when the temporary smart pointer object goes out of scope of the helper function, it should also delete the joint automatically. It does not happen, but obviously i do not understand what smart pointers are good for in practice. I do know a bit about them, but i never was in a situation where i needed reference counting, and i'm worried about the cost to do this in a thread safe manner.

[JoeJ]

I found the reason for the strange crashes, it's Clang.
Usually when i go to Project Settings, i see the settings for the currently selected config. But for soem reason i always was changing Debug settings accidentally, which i did not notice.
After making sure MSVC is used for release the crashes went away.

That's something you really should look into. It seems Clang is the default compiler for game development.
Recently i did some BVH traversal, and Clang was 200 times faster than MSVC. I don't believe this myself, but verified a few times.
Usually i see a speed up of 30% in my other big project, which is bottlenecked by storage speed.

No idea what's the problem. Because the crashes make no sense i'd guess it's something stupid like misaligned memory for SIMD access. Although that certain problem should be gone with x64 these days.


Likely i'll come back with further questions about the smart pointers. I still have crashes on exit i did not have before, but i hope the above finding clarifies some confusion before i get into details.

[JoeJ]

Code: Select all

      ~Simulaton ()
      {
         if (ipTest)
         {
            world.RemoveModel(ipTest);
            //delete ipTest; // crashes - why?
         }
      }


Ok, so here the question:
I assume RemoveModel() already deletes the model, because i have no smart pointer left pointing to it? (could not really verify by stepping in with debugger)

This means i never have to delete stuff myself. It happens automatically.
But i could set the ipTest pointer to null eventually, to make clear the object is gone.

If i wanted to remove the model just temporally, but later re-enable it, i could do so by having a smart pointer pointing to it.

And i assume this applies to all other things as well, like bodies or joints.

Did i get this correctly?

If so, what's the benefit in practice? What kind of problem does this solve?
Currently i only see increased complexity and chance to introduce bugs, but i fail to get the advantage.

Edit: I also commented out deleting bodies and joints of a model in the deconstructor:

Code: Select all

   virtual ~InvertedPendulumTest ()
   {
      //if (bodyTorso) delete bodyTorso;  // crashes - why?
      //if (bodyFoot) delete bodyFoot;
      //if (joint) delete joint;
   }


Which raises the same questions, but kind of nested:
When does Newton delete those bodies and joints automatically?
And how do i prevent it in case i want to remove just temporally?

[Julio Jerez]

oh there are few things here. let us first go with Clang / VS. build

on this when a program crashes with one compile and no with other, it is usually because some comiler setting in one is not doing the same one other.
I has not try Clang since VS 2017, I am trying again with VS 2017

the way I do it first, make sure teh tool set is installed in VS.
https://devblogs.microsoft.com/cppblog/ ... al-studio/

after doing that, in cMake, in Optinal Toolset to use
I put: CLangCL

then I generate the build and I get a Visual studio solution that use Clang as front end compiler.
after that I compile and run.

I get lot of warning, stuff like
in header

#ifndef _ND_FILE_FORMAT_SHAPE_H__
#define _ND_FILE_FORMAT_SHAPE_H__

clang give this warning

7>In file included from E:\newton\newton-dynamics\newton-4.00\sdk\dFileFormat\./ndFileFormatShapeConvex.h:26:
7>E:\newton\newton-dynamics\newton-4.00\sdk\dFileFormat\./ndFileFormatShape.h(23,9): warning : macro name is a reserved identifier [-Wreserved-id-macr

or in code like this

Code: Select all

inline ndWorld* ndScene::GetWorld() const
{
   return nullptr;
}

Clang reports:

11>E:\newton\newton-dynamics\newton-4.00\sdk\dCollision/ndScene.h(208,9): warning : 'nullptr' is incompatible with C++98 [-Wc++98-compat]

then when I runs the sand box I see a very different behavior. that I do no think happens with visual studio.

I am using the simple industrial and advanced industrial robot demos. and the behave really bad, and the secund evenetually crashes even in debug, so it something is really wrong.
I need to check that.

on the smart pointer, can you please make a seprate thread?

[Julio Jerez]

ok, I just try the visual studio build and act the same bad way.
I probably broke something at some point.

I will have to compere to older version and see when this started to happen.
I do not remember it been this bad.
so that the first this we have to fix.

I will test that this weekend.

[JoeJ]

after doing that, in cMake, in Optinal Toolset to use
I put: CLangCL

Alternatively, you can just go to Project Properties and change Platform Toolset to Clang. Then clean and rebuild.
I switch between MSVC and Clang pretty often this way because MSVC has much shorter compile times.

About the warnings, i still have thousands of them for my other project.
Some day i'll fix them all, so i can see those which actually matter

It might be worth to update to the latest VS. Clang support feels more robust recently.
I've had such strange crashes in my project too using VS 2017. After reinstalling VS it sometimes worked, or it did no longer work at all.
So it's totally possible the current problem is just a VS bug i guess.

Personally i'm always quick with updating VS.
Because i always hope they finally fix subtle bugs which annoy me for years.
But then they never do.

ok, I just try the visual studio build and act the same bad way.
I probably broke something at some point.

Simulation itself works very well for me.
So i guess you broke something on your IK solver eventually.

[Julio Jerez]

Yes, I think I broke something in the ik solver yes.

[Julio Jerez]

wow, It is going to take a few days for me to merge the code, since I made the last stable relase.

I made lot of changes in many directions,
the Deep Learning, the file format, and plenty of changes to the joint and solvers.

The differences are there, but I have to add each of those change, in insulation to see where the I broke, the code.
But yesy, I seems I broke something really bad.

[Julio Jerez]

ah, I think I found the bug,
I think it happen when I introduce the principal axis inertia to the ndKinematicBody.

basically, the engine by default bodies assumed a rotation matrix always aligned to the principal axis of inertia.

This is not too far from almost 95 or more % of all application, because of symmetry, but is not general.

you get a skew inertia, that app would have to subclass for ndDynamics and override the function to calculate the inertia. this required lot of domain knowledge of teh engine for most users, so I decided to make it general.

It seemed to work very nice when I tested it, but here I did not count on that now every object with a and asymmetrical collision, is now going to have a skew inertia.

that should not be a problem, but what is does is that introduce a very strong nonlinearity and will make object behave probably the way that user do not expect.

I have finish merging all the other changes, but that seem the problem,
if so, I will add some function that allow the app to override the calculated inertia.
Maybe a extra parameter that for to select the principal eigen values and disregard the skew values.

I believe this happen on the vehicle, which now seem to exhibit an estrange problem after those changes.

anyway, if this is the case, them is not a big problem, and I can test the ClangCL in release mode.

[JoeJ]

Oh, already saw the principal axis and wondered what it is.

But i was thinking about this problem before, and planned to address it like this:
If any given default orientation of some object is a bad match for inertia, calculate the best fit orientation and rotate the objects vertices accordingly.
This would not work for primitives like boxes or cylinders, but those are symmetrical anyway and default orientation is always ideal, assuming mass density is uniform.
Ofc. users need to be smart enough to come up with this, if there ever is a problem of inertia being noticeable bad. And they need to handle the now different orientation of the object on their side.

However, not sure if you really need this feature. A skew allows a bit more expression than a rotation, but a skewed ellipsoid still looks like an ellipsoid, so the extra expression isn't much.

Where does the feature have an effect? Compounds?

[JoeJ]

Coincidentally i have just made the callback to calculate inertia at given direction.
My pendulum model needs this, and it treats the ragdoll (or parts of it) as a single body, like a compound.

Plotting this, i always get those lobe alike shapes:

inertia.JPG (86.26 KiB) Viewed 6422 times

The magnitude of the green vectors is the inertia about their direction. No way you can represent this with an ellipsoid, skewed or not.
(I hope i did this correctly, like always )

This always makes me think it would be interesting to store inertia with higher order spherical harmonics, which can represent such function pretty well.
I also think it's north worth it, expecting too bad effect on simulation stability.
But would be interesting to try out for fun.

[Julio Jerez]

this is simple rigid body mechanic. you can get a crash course in wikipedia.
https://en.wikipedia.org/wiki/Moment_of_inertia

look at the part where they talk of principal axis.
"Inertia matrix in different reference frames"

basically, the moment of inertia of a matrix can be decompose int a rotation matrix and a scale vector.
the equation is this

II = R1 * E * R1t

II is inertia,
R is rotation
E is the eigen values of II, which correspond to the local moment of inertia

since E is constant, them it makes sense to store the Inertia by its components.
for most bodies with an axis for symmetry, vector E will have duplicate values.
and R will be identity. example are: sphere a cube been the most typical ultimate symmetric bodies.

if you set the condition that the body will be oriented according to Matrix R
them, for a large set of objects, the calculation above calculation is simple.
Cars, Bicycles, boxes, cylinder, almost any practical body in nature has some axis of symmetry.

but let us say you want to simulate an asteroid. in general, those objects has not symmetry at all,
that is :

E.x != E.y != R.z

in that case you cannot assume any alignments.
in that case you the class must store E and R

them the calculation become.

II = R * R1 * E * R1t * Rt

now R1 is the skew matrix of inertia that represents a full general inertia matrix.

when the body has symmetry them R1 is identity, and the equation reduces to the simple one.

there are other things that get affected stuff like calculate angular momentum, Centripetal, an all-velocity dependent force. as well as the integration.

I already brought that code to the state it was before the change, later I will try again but this time I will add a #ifdef so that it can be tested before making it final.

[Julio Jerez]

the things that been able to simulate General Inertia allow is simulation like this.

https://www.youtube.com/watch?v=BCVQFoPO5qQ

I know it is such an edge and extreme case, but a am of the opinion that a rigid body simulation should at least in principle recrate those kind of effects.