Unmanaged crash in Physx (5.5.4.p1)

We have a new problem with Physics. We get an unmanaged crash while playing the game, here is the stack traces from two different machines

Also we get this exception without unmanaged crash

 

Should we submit a bug report maybe? This bug is serious for us since our game is in early access on Steam and thus already Published

 

I opened a bug we need this sorted ASAP

 

We are getting desperate here guys, the crash has only happened two times so far, but we get alot of these kind of errors. Sometimes with complete loss of framerate, sometimes you dont even notice it.



edit: This bug happened because we had a bug in our Spawn logic. For some frames all spawed items shared the same position which seemed to completly fubar physics. Its now fixed. The crash bug still happens and is probably not related at all to this problem

 

Some bugs related to our problems that have gotten no attention from Unity it seems :/

https://issuetracker.unity3d.com/is...use-it-was-infinity-or-nan-appears-in-console

https://issuetracker.unity3d.com/is...hile-colliding-the-edge-of-another-gameobject

 

maybe test copy of the project in newer unity/beta version, just to see if still happens?

 

We have tested 2017.2b9 Same thing, not the crash (Only happened two times) but we get the other exceptions.

 

could replace mesh colliders with primitive ones, if that makes any difference?

 

We have only primitive colliders on our rigidbody objects

 

Ok, got a bug report from one of our customers

 

Another customer reports complete crash of game

Unity please help us out, we are a bit desperate here

 

I have tried 5.5.4.p5 which above crash was using, so no difference there

 

I would suggest to set up many sanity checks around the area where the problem happens.

Sanity checks means setting up code that will verify incoming values for being NaN/INF and if anything is wrong, trip a breakpoint or dump all information you can into the logfile.

If you can catch some sort of exception when the problem happens, I'd recommend to print transformation for the entire hierarchy at this point. Meaning starting from current object, print transform.localRotation, transform.localScale, transform.localRotation. Local, not global. Then print the same info for each of the object's parents, walking hierarchy upwards towards root.

Most likely scenario that for whatever reason somewhere in your code there's a numerical error which results in weird behavior. Meaning a value is too small, too large, or some sort of risky operation is performed without checking.

------

Now, regarding the second crash log... I'd suggest to try to pinpoint the code block that leads to it. For example, once upon a time, I've run into issue where OverlapBox would crash the game on android. However, I do not actually see any physx call in the stack trace, so it is unclear if this one even is a physx bug and not some sort of obscure local problem.

 

Those errors in that screenshot is fixed, it was a problem on our side. Its not related to the crash, should update the other thread about that.

We do have a check now for nan, and if it occurs we log and revert to last known correct value. The crash have happened once since this fix.
And during playtets we do detect some Nan values on the transforms. But its not because of our code, we check our netcode values carefully before we update the transforms, and for netwroked controlled objects we have disabled rigidodies. Its the physics engine that sets these invalid nan values

 

I should also state that the physics in our game is on a different level than most games

 

A much better idea would be to figure out what exactly causes nan values and fix the problem there. Reverting to the last known value is quick fix at best.

 

Yeah thats what the logging is there for, we also have a Debug.Break, but its seldom we do playtests in editor mode and it have never been reported since we starting logging

 

I created a new thread with a video showing some theories around whats causing the problem

https://forum.unity.com/threads/problem-with-physics-in-a-very-physics-driven-game.497186/

 

Bit late for anyone in this thread I imagine, but we had a similar issue and finally tracked this down to an animation that set the scale of an object with a RigidBody Component to 0, 0, 0. Pretty clear to see how that could introduce some divide by zeros in our IL2CPP build.

Fixed by changing to 0.001, 0.001, 0.001