Crash calling fetchResults(true) after simulate()

I recently upgraded from 3.3.0 to 3.3.2 and now when I load my scene I get an assertion on the first fetchResults(true) call after simulate()

…\workphysx-3.3.2_windows_sdk_core\source\foundation\include\PsArray.h(181) : Assertion failed: i < mSize

This has never happen in previous versions, and the scene hasnt really changed. I have other physx programs that I tested, and they run under 3.3.2.

The call stack after hitting retry in the assertion window is

PhysX3CommonDEBUG_x86.dll!55d7f9d5()	Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for PhysX3CommonDEBUG_x86.dll]	
PhysX3DEBUG_x86.dll!52a6cc59()	Unknown
PhysX3DEBUG_x86.dll!52b75eec()	Unknown
PhysX3DEBUG_x86.dll!52b4e296()	Unknown
PhysX3DEBUG_x86.dll!52cc5914()	Unknown
PhysX3DEBUG_x86.dll!52cd4029()	Unknown
PhysX3DEBUG_x86.dll!52ad68be()	Unknown

PhysicsSupport_dbg_vs10_MDd.dll!physx::Ext::DefaultCpuDispatcher::runTask() Line 183 C++
PhysicsSupport_dbg_vs10_MDd.dll!physx::Ext::CpuWorkerThread::execute() Line 97 C++
PhysX3CommonDEBUG_x86.dll!55d7d3dc() Unknown
kernel32.dll!775b338a() Unknown
ntdll.dll!77cb9f72() Unknown
ntdll.dll!77cb9f45() Unknown

Its a single threaded 32bit windows program, running on windows 7 64, physx 3.3.2 sdk/binaries dlls

Are you loading binary serialized scene?

No sorry, by scene I mean a scene which I created that used physx objects for collision that up until this point had no problems. It doesnt use any physx format for loading or saving, the objects are being created manually from scratch.
Its mostly static actors a few controllers and handful of dynamics, no particles or joints or anything advanced, which makes a crash like this strange.

Are you loading inserting many shapes onto one global position in the scene, and then moving them?

I may have been, would that error happen when any type of objects were placed in the same location and moved? I believe I may have done this with some dynamics/controllers, Im pretty sure I created the statics in their final locations.
I had to go back to 3.3.0 to continue some work, so Ill have to try again soon with the newer SDK.

I think I have seen issues in the past where objects were created, for example at the origin, and then moved far across the scene using a kinematic “MoveTo”, and this caused a huge churn in creating potential collision pairs, which then overflowed some buffers.