Hello,
We are experiencing frequent, seemingly random native crashes on Magic Leap 2 devices across our fleet, all running OS build B3E.240905.12-R.038. These crashes occur on multiple different devices and persist across Unity editor and package version upgrades.
Our Unity app has shown these issues when built with Unity 6000.0.45f1 and 6000.3.11f1, we also use OpenXR features related to hand tracking, localization, meshing, and spatial anchors. The exact list is shown in the attached screenshot.
The app is crashing with SIGILL and SIGSEGV signals originating from within Magic Leap’s native libraries — primarily libml_perception_session.so and libunity.so. We are also seeing identical crash patterns in the Leap Brush sample app (com.magicleap.leapbrush), which leads us to believe the root cause is deeper than our application code. Here’s a tombstone from the bugreport taken that captures the crash in the LeapBrush app, as well as the log file.
bugreport-demophon_aosp-B3E.240905.12-R.038-2026-03-13-13-34-04.txt (8.6 MB)
leapbrush tombstone_09.txt (1.0 MB)
Here are the descriptions of the crashes we see with our app:
- SIGILL in libml_perception_session.so during pose queries
The most common crash. The stack trace shows xrLocateSpace → Session::GetPose → ml_pose_combine_fn hitting an illegal instruction. We have captured multiple identical instances of this crash back-to-back on the same device (see the attached tombstone_08 and tombstone_09).
- SIGSEGV in magicflinger during head tracking
We captured a crash in the system compositor (magicflinger) where HeadTracking::RePredictPose in libml_perception_head_tracking.so segfaulted during CompositorBackend::UpdatePerceptionState. This crash caused a full device restart.
- SIGILL in xrSyncActions during input update
Captured via Sentry — a SIGILL crash in the OpenXR input provider during xrSyncActions, called from Unity’s XRInputSubsystem::Update in the normal player loop.
- Massive XR runtime stalls (3–20 seconds)
Using the Unity Profiler, we captured two instances of the OpenXR runtime stalling on the main thread:
- EarlyUpdate.XRUpdate blocked for 3,400 ms
- FrameEvents.XRBeginFrame blocked for 20,000 ms
In both cases, there was nothing underneath these calls in the profiler — Unity is waiting on a single native call into the OpenXR runtime that simply does not return for seconds at a time. These stalls cause display loss on the headset.
- Spatial anchor crashes
We also captured a SIGABRT from an uncaught ml::perception::Exception in SpatialAnchor::UpdateTrackedAnchors().
What We Have Tried:
- Upgrading Unity editor versions
- Upgrading ML2 Unity packages
- Removing spatial anchor usage from our localization system
- Profiling to identify any application-side cause
From our application (8 crashes on a single device, Feb 11 – Mar 4):
- tombstone_00 — SIGILL in worker thread (Mar 4)
- tombstone_02 — SIGABRT on UnityMain (Feb 11)
- tombstone_03 — SIGSEGV in FMOD mixer thread (Feb 17)
- tombstone_05 — SIGABRT from SpatialAnchor::UpdateTrackedAnchors() (Feb 20)
- tombstone_06 — SIGSEGV in worker thread (Feb 24)
- tombstone_07 — SIGSEGV null pointer, kernel-generated (Feb 25)
- tombstone_08 — SIGILL in xrLocateSpace / libml_perception_session.so (Mar 3)
- tombstone_09 — SIGILL in xrLocateSpace, identical to tombstone_08 (Mar 3)
- bugreport-demophon_aosp-B3E.240905.12-R.038-2026-03-04-13-44-34.txt — Full system log from this device
Entire bugreport zips were too large to upload here, but I can send them if they would be helpful. Any guidance as to how to increase the stability of our app on the headset and to mitigate the multi-second stalls in xrBeginFrame and xrSyncActions would be greatly appreciated. Thanks.
bugreport-demophon_aosp-B3E.240905.12-R.038-2026-03-04-13-44-34.txt (9.2 MB)
tombstone_00.txt (1.1 MB)
tombstone_03.txt (1.2 MB)
tombstone_09.txt (1.2 MB)
tombstone_08.txt (1.2 MB)
tombstone_07.txt (1.1 MB)
tombstone_06.txt (1.3 MB)
tombstone_05.txt (1.3 MB)
tombstone_02.txt (2.1 MB)