Crash in EngineCollisionEventDelegate::updateCollision

We are seeing a lot of crashes when running in the simulator and on device. We haven’t been able to find the cause of the crashes, but they seem to happen when objects enter a trigger or collides with certain objects. The crash doesn’t happen every time, and I have not yet been able to consistently reproduce the issue. I have attached the crash report from the simulator.

Any ideas of what to look for?

Exception Subtype: KERN_INVALID_ADDRESS at 0xffffffff00000018
Exception Codes: 0x0000000000000001, 0xffffffff00000018
VM Region Info: 0xffffffff00000018 is not in any region.  Bytes after previous region: 18446638515761446937  
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      MALLOC_NANO (reserved)   600018000000-600020000000 [128.0M] rw-/rwx SM=NUL  ...(unallocated)
Triggered by Thread:  0

Thread 0 Crashed::  Dispatch queue:
0   CoreRE                        	       0x1a62f5344 re::EngineCollisionEventDelegate::updateCollision(re::CollisionObject const*, re::CollisionObject const*, re::ContactSet const&) + 420
1   CoreRE                        	       0x1a5d86ad4 re::CollisionWorld::reportTriggerEvents() + 460
2   CoreRE                        	       0x1a5d7e584 re::PhysXCollisionWorld::reportCollisions() + 56
3   CoreRE                        	       0x1a612b878 re::ecs2::ECSSimulationEventDelegate::postSimulation(float, re::PhysicsSimulation&) + 112
4   CoreRE                        	       0x1a65ad878 re::PhysicsSimulation::update(float) + 392
5   CoreRE                        	       0x1a5e38694 re::ecs2::PhysicsSystem::update(re::ecs2::Scene*, re::ecs2::System::UpdateContext) const + 652
6   CoreRE                        	       0x1a62f6ebc re::ecs2::System::update(re::ecs2::System::UpdateContext) const + 104
7   CoreRE                        	       0x1a630f9d4 re::internal::Callable<re::ecs2::ECSManager::configurePhaseECSSystems(re::Scheduler::ScheduleDescriptor&, re::ecs2::ECSSystemGroup, unsigned long)::$_8, void (float)>::operator()(float&&) const + 132
8   CoreRE                        	       0x1a6775430 re::Scheduler::executePhase(unsigned long) + 428
9   CoreRE                        	       0x1a5ac2da4 re::Engine::executePhase(re::FramePhase) + 144
10  RealitySystemSupport          	       0x1da50cea8 rcp::SharedSimulation::execute() + 32
11  RealitySystemSupport          	       0x1da5bb3e4 rcp::SharedSimulation::perform_update() + 196
12  RealitySystemSupport          	       0x1da5bab68 rcp::SharedSimulation::handle_frame_boundary() + 176
13  RealitySystemSupport          	       0x1da5bba08 invocation function for block in rcp::SharedSimulation::_ensure_add_transaction_handler() + 128
14  QuartzCore                    	       0x18a01562c CA::Transaction::run_commit_handlers(CATransactionPhase) + 112
15  QuartzCore                    	       0x189fe5320 CA::Context::commit_transaction(CA::Transaction*, double, double*) + 584
16  QuartzCore                    	       0x18a014e88 CA::Transaction::commit() + 652
17  QuartzCore                    	       0x18a01630c CA::Transaction::flush_as_runloop_observer(bool) + 68
18  UIKitCore                     	       0x1852d2f98 _UIApplicationFlushCATransaction + 48
19  UIKitCore                     	       0x1848e8040 _UIUpdateSequenceRun + 76
20  UIKitCore                     	       0x1852155cc schedulerStepScheduledMainSection + 140
21  UIKitCore                     	       0x185214b78 runloopSourceCallback + 80
22  CoreFoundation                	       0x180402128 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
23  CoreFoundation                	       0x180402070 __CFRunLoopDoSource0 + 172
24  CoreFoundation                	       0x1804017e0 __CFRunLoopDoSources0 + 232
25  CoreFoundation                	       0x1803fbef8 __CFRunLoopRun + 768
26  CoreFoundation                	       0x1803fb7f4 CFRunLoopRunSpecific + 572
27  GraphicsServices              	       0x18ed4ec20 GSEventRunModal + 160
28  UIKitCore                     	       0x1852d45c4 -[UIApplication _run] + 868
29  UIKitCore                     	       0x1852d8264 UIApplicationMain + 124
30  SwiftUI                       	       0x1c6e3fa44 0x1c5ea2000 + 16374340
31  SwiftUI                       	       0x1c6e3f8d4 0x1c5ea2000 + 16373972
32  SwiftUI                       	       0x1c6ade164 0x1c5ea2000 + 12829028
33  WHAT THE GOLF?                	       0x102882aa8 static UnitySwiftUIiPhoneApp.$main() + 52 [inlined]
34  WHAT THE GOLF?                	       0x102882aa8 main + 64
35  dyld_sim                      	       0x10306d558 start_sim + 20
36  dyld                          	       0x1031f9f28 start + 2236

No ideas, exactly, but we have seen this crash as well. In the words of @DanMillerU3D : “this was forcing a box collider inside another box collider, I was also seeing this when I was moving an object through the path of another collider.” We believe this to be a RealityKit bug.

Good to know that it’s not just happening here. We are almost completely blocked by the issue, so we are looking for ways around it. If we could modify the ColliderTracker such that it only tracks a single collider used for indirect pinch input, I think we could get around the problem. Is there any support for custom trackers that I haven’t seen yet? Or is it planned?

No support for custom trackers, and I’m not aware of any plans for any; they tend to depend on internal APIs.

The ColliderTracker does have a way of filtering the GameObjects it tracks, though. In Project Settings/PolySpatial, there’s a “PolySpatial Collider Layer Mask” which defaults to the “Default” layer. If it’s possible to put the single collider you want to track into a different layer and set the layer mask to include only that layer, it seems like you could just track that one collider.

If you do find a case that reproduces the bug consistently, though, definitely less us know. It would help us report the issue to Apple.

Ah great, that was what I was looking for. Thanks!

I’ll try to see if I can reproduce. I was also getting some really weird input behaviour with all colliders being being tracked. Sometimes it just didn’t report the “began” phase. I’ll let you know if I find anything.

Hi there!

Any update on this? I’m hitting the same exception. Any developments on the state of the issue on the RK side of it?

Weirdly, when I attempt to recreate the issue in a clean project, I can’t.

We have a change that will be included in the next bugfix release that should address this issue (I believe it’s related to the crash described in this thread).

As far as the RK side of things, we create colliders in RealityKit that correspond to the Unity ones, along with additional colliders for raycastable UI elements (in order to receive input events: touches/pinches). We only use these colliders in RealityKit for raycasting, which means that they can all be static/triggers (whereas before, we created default colliders). Making this change seems to fix the crash and should also be better for performance.

1 Like