Crash Bug

Gaming and Visualization Technologies APIs Physics Modeling (closed)
1

Hello there,

I’m getting a very weird crash bug. It doesn’t happen on Debug. It only happens in Release and it is definitely PhysX. I don’t get a single error/warning message in the output window of Visual Studio when I run it in Debug. I wish I had the source to PhysX it would make life so much simpler, but here is what I know so far:

It crashes in PhysX3_x64.dll.
This is the call stack from the crashing thread:

PhysX3_x64.dll!00007ff9fc604774()	Unknown
 	PhysX3_x64.dll!00007ff9fc604d28()	Unknown
>	MEHGameEngine.exe!physx::Ext::CpuWorkerThread::execute() Line 110	C++

Also, it’s during the fetchResults (blocking) of my update thread. The call stack for that thread is:

ntdll.dll!00007ffa3fe0ad4a()	Unknown
 	KernelBase.dll!00007ffa3d491148()	Unknown
 	PhysX3Common_x64.dll!00007ff9fbf12d78()	Unknown
 	ApexFramework_x64.dll!00007ff9fb2786fd()	Unknown
>	MEHGameEngine.exe!MEHWorld::Update(float elapsedSecs) Line 919	C++

I’ll keep investigating, but some help would be greatly appreciated.

Cheers,
Mike

2

OK I’ve cornered it down to the following line which gets called once per frame outside of simulate+fetch:

((PxRigidDynamic *)m_physXBody)->setLinearVelocity(*(PxVec3 *)&dv);

Funny thing is, it doesn’t do it in debug mode. How am I certain it’s this line? Because I used an age variable and it crashes right when times up:

if (m_age > (scalar)2.0)
   ((PxRigidDynamic *)m_physXBody)->setLinearVelocity(*(PxVec3 *)&dv);

Now I know it’s a little unconventional to set the linear velocity yourself, but it’s an action game and I need the freedom and responsiveness. If it was a tank or helicopter game, I could just use addForce/addTorque to get the job done, but it’s not. Anyway, I’m working on finding a work-around, any advice would be appreciated.

Cheers,
Mike

3

Solved. Refer to [url]https://developer.nvidia.com/sites/default/files/akamai/physx/Manual/DataAccess.html#locking-semantics[/url]. I solved it by locking the scene before setting the linear velocity. Phew, that was a tough one to solve!

4

I’m interested in this issue. Were you setting the linear velocity in between the call to simulate and fetch ? Setting the linear velocity for a body outside of simulate and fetch is perfectly legal. There is no stipulation that the simulation have to drive the entire motion of a body. I was experiencing a crash at shutdown ( currently tested my debug build only ), and I was invoking setLinearVelocity before the call to simulate and fetch.

5

No, my simulate/fetch has a current width of zero unfortunately. Perhaps when I get to the optimization phase, I can put more instructions in between them. Anyway, the crux of the issue was that I’m using APEX Cloth/Destructibles and what they do is they wrap around a PhysX scene. The documentation says the manual locking/unlocking is required particularly when there is more than one subsystem making calls, in my case APEX and my game both use the inner PhysX scene wrapped in the APEX scene. So I think that was the problem.

Hope this helps,
Mike

6

Ok I should probably test things out more before I post anything. Turns out the one time I thought I solved the problem, I must have had a lucky run because it just crashed on me again (AFTER I put all my API reads in a “lockRead” and all my API writes in a “lockWrite”.)

I don’t know what it could be. I’ll update the thread just as soon as I find out.

7

So I THINK I solved it. PhysX can’t handle very small numbers I think. And it’s only in Release which is weird. In Debug it doesn’t exhibit this behavior. Here’s how I solved it:

if (m_storedUpVelocity.Magnitude2() > MEHEPSILONVERYSMALL*MEHEPSILONVERYSMALL)
   ((PxRigidDynamic *)m_physXBody)->setLinearVelocity(*(PxVec3 *)&m_storedUpVelocity);
else
   ((PxRigidDynamic *)m_physXBody)->setLinearVelocity(*(PxVec3 *)&MEHVector3::Zero);

So basically, if it’s a very small number, use zero instead. How small are we talking? e-12 or e-13. The reason it’s so small is because we exported the animation from Maya and even though the character just sits there, some weird small numbers have crept into the simulation.

My advice to NVIDIA is to clamp small velocities to zero for the user, but I understand how you guys dislike to put in checks for performance reasons. Hell, your 3-vector normalization function comes in two versions, one WITH an if statement and one without. That’s really conscious about performance.

Anyway, I will mark this one up as my fault for feeding PhysX incredibly small numbers. It may still crash, but I just ran the game 4 times and each time I went to 4 different rooms (each room has a 25% chance or so of failing) so I’m pretty confident it’s gone. I thank the wall that is the forum admin for listening to me ramble.