PhysX 3.4 crash in ScScene.cpp line 2406

This is possibly related to https://github.com/NVIDIAGameWorks/PhysX-3.4/pull/7, although the fix suggested did not work.

I am getting frequent crashes that appear to be caused by heap corruption. I was able to catch a crash on the following line in the debugger:

markerIter[suppressedStartIdx + i] = mNPhaseCore->mInteractionMarkerPool.allocate();

The value of nbToSuppress was very large (81728531).
It appears that this line is writing outside the bounds of the array. The mPreallocatedInteractionMarkers array had mSize=1 and mCapacity=7.

Still getting crashes in 3.4 RC2.

Hi

Would you be able to provide a repro of this issue for further investigation? If not, could you provide a few more details at least, e.g. what are the values of:

suppressedCurrIdx

suppressedStartIdx

used in this code?

const PxU32 nbToSuppress = suppressedCurrIdx - suppressedStartIdx;

Do they look valid or completely invalid? Is suppressedCurrIdx smaller than suppressedStartIdx?

Thanks

Kier

Hi, any news on this?

I seem to get the same crash (or actually one of ~5 different crashes selected randomly). Building the PhysX libraries with optimizations disabled I got this callstack:

>	PhysX3CHECKED_x64.dll!physx::shdfnd::PoolBase<physx::Sc::ElementInteractionMarker,physx::shdfnd::NamedAllocator>::allocate() Line 73	C++
 	PhysX3CHECKED_x64.dll!physx::Sc::Scene::preallocateContactManagers(physx::PxBaseTask * continuation) Line 6409	C++
 	PhysX3CHECKED_x64.dll!physx::Cm::DelegateTask<physx::Sc::Scene,&physx::Sc::Scene::preallocateContactManagers>::runInternal() Line 98	C++

With the crash:

Exception thrown: read access violation.
this->mFreeElement was 0x1CDCDCDCDCD.

Here suppressedCurrIdx was 118 and suppressedStartIdx was 0, mPreallocatedInteractionMarkers had size 118.

I have a repro case that crashes somewhere 100% of the time, but unfortunately I don’t have a simple code snippet to share.

I’ll try again tomorrow to catch this in the debugger.
I occasionally get crashes in other places, but I think that they are caused by heap corruption that stems from the lines that I mentioned.

I also have a 100% repro case, but it also is not a simple scene. The crash always occurs upon calling PxScene::removeActor(). I don’t have a lot of physics actors in the scene (fewer than 100) and most of these are static.

I should be able to provide more information tomorrow.

Looks like I was able to work around this by using eKILL instead of eSUPPRESS in the filter shader.

I wrote some tests to hammer eSUPPRESS and, so far, I’ve still not been able to repro this issue. I expect eKILL will work around the issue but it would be massively appreciated if we could get enough info for us to be able to repro and fix this issue.

I get an assertion in ScShapeInteraction.cpp on line 862 a few seconds before the crash:

PX_ASSERT(activeManagerAllowed());

The variable values at the time of the crash were:

• createdCurrIdx = 1
• createdStartIdx = 0
• suppressedCurrIdx= 4
• suppressedStartIdx = 0

I have also exported a Visual Studio dump file: https://www.dropbox.com/s/bb7yt76k9xundu4/CrashDump.dmp?dl=0

Changing to eKILL works for me also.

Hi again,

I’m not sure if this is still the same issue, but I found a new crash / threading issue. I get a crash (trying to access deleted memory) in:

>	PhysX3CHECKED_x64.dll!physx::Sc::BodySim::isConnectedTo(const physx::Sc::ActorSim & other, bool & collisionDisabled) Line 915	C++
 	PhysX3CHECKED_x64.dll!physx::Sc::NPhaseCore::filterRbCollisionPair(const physx::Sc::ShapeSim & s0, const physx::Sc::ShapeSim & s1, unsigned int filterPairIndex, unsigned int & isTriggerPair, bool runCallbacks) Line 1411	C++
 	PhysX3CHECKED_x64.dll!physx::Sc::NPhaseCore::onOverlapFilter(physx::Sc::ElementSim * volume0, physx::Sc::ElementSim * volume1, physx::Bp::BroadPhasePair * pair) Line 216	C++
 	PhysX3CHECKED_x64.dll!OverlapFilterTask::runInternal() Line 6174	C++
 	PhysX3CHECKED_x64.dll!physx::Cm::Task::run() Line 63	C++

and in another thread I have this happening:

>	PhysX3CHECKED_x64.dll!physx::Sc::ActorSim::reallocInteractions(physx::Sc::Interaction * * & mem, unsigned int & capacity, unsigned int size, unsigned int requiredMinCapacity) Line 104	C++
 	PhysX3CHECKED_x64.dll!physx::Sc::ActorSim::registerInteraction(physx::Sc::Interaction * interaction) Line 57	C++
 	PhysX3CHECKED_x64.dll!physx::Sc::TriggerInteraction::TriggerInteraction(physx::Sc::ShapeSim & tShape, physx::Sc::ShapeSim & oShape) Line 51	C++
 	PhysX3CHECKED_x64.dll!physx::Sc::NPhaseCore::createTriggerInteraction(physx::Sc::ShapeSim & s0, physx::Sc::ShapeSim & s1, physx::PxFlags<enum physx::PxPairFlag::Enum,unsigned short> triggerFlags) Line 874	C++
 	PhysX3CHECKED_x64.dll!physx::Sc::NPhaseCore::createRbElementInteraction(const physx::PxFilterInfo & finfo, physx::Sc::ShapeSim & s0, physx::Sc::ShapeSim & s1, physx::PxsContactManager * contactManager, physx::Sc::ShapeInteraction * shapeInteraction, physx::Sc::ElementInteractionMarker * interactionMarker, unsigned int isTriggerPair) Line 692	C++
 	PhysX3CHECKED_x64.dll!physx::Sc::NPhaseCore::createRbElementInteraction(physx::Sc::ShapeSim & s0, physx::Sc::ShapeSim & s1, physx::PxsContactManager * contactManager, physx::Sc::ShapeInteraction * shapeInteraction, physx::Sc::ElementInteractionMarker * interactionMarker) Line 727	C++
 	PhysX3CHECKED_x64.dll!physx::Sc::NPhaseCore::onOverlapCreated(physx::Sc::ElementSim * volume0, physx::Sc::ElementSim * volume1, const unsigned int ccdPass, physx::Bp::BroadPhasePair * pair) Line 348	C++
 	PhysX3CHECKED_x64.dll!physx::Sc::NPhaseCore::onOverlapCreated(const physx::Bp::AABBOverlap * pairs, unsigned int pairCount, const unsigned int ccdPass, physx::Bp::BroadPhasePair * bpPairs) Line 463	C++
 	PhysX3CHECKED_x64.dll!physx::Sc::Scene::finishBroadPhase(const unsigned int ccdPass, physx::PxBaseTask * continuation) Line 6479	C++
 	PhysX3CHECKED_x64.dll!physx::Cm::Task::run() Line 63	C++

Apologies if the line numbers don’t exactly match, I added some test code there to find out what was happening.

It seems that the interactions array isConnectedTo() is looping through gets reallocated in another thread. Disabling threading or disabling triggers seems to prevent the new crash and the old crash from happening.

Unfortunately again I don’t have a simple test case to share, but I have a test scene set up in our game where I can repro this crash quite easily.

Thanks Ikkah. This gives me something to go on. If there is a race condition between these 2 stages, it should be easy to fix

Kier

I have a fix for this race condition. Whether this is the source of the crash you reported, I don’t know, but it seems plausible. We’re starting to push patches to 3.4 on GitHub and this fix should hopefully be included in the next patch.

If you want to replicate the fix, I moved the code that loops over all the particle, cloth and trigger interactions calling mNPhaseCore->onOverlapCreated(…) before the code that launches the OverlapFilterTasks so that the two should not interfere with each other.

Cool, thanks, that fixes both crashes for me.