SIGABRT (internal abort) on ms_depth thread during depth-from-motion under sustained low-confidence conditions — Pixel 10 Pro

[jlberner]

Our Unity AR app (AR Foundation 6.4.3, ARCore XR Plugin, environment depth mode Best with temporal
smoothing) experienced a native abort inside ARCore's motion-stereo depth thread. The full process
was killed (SIGABRT is uncatchable in-process).

Device / environment:

• Pixel 10 Pro (google/blazer/blazer:16/CP1A.260505.005/15081906:user/release-keys)
• Android kernel 6.6.102-android15-8
• Google Play Services for AR 1.54.260890093 (com.google.ar.core)
• ARCore libarcore_c.so BuildId: 15fc3723f0012d756162123aa00372fd
• Unity 6000.4.9f1, AR Foundation 6.4.3, IL2CPP ARM64
• Timestamp: 2026-07-05 20:59:26 CDT, process uptime 103s

Context leading to the crash:

• Outdoors approaching dusk (fading light — dim, but a normal usage window, not darkness). The
  environment depth stream was delivering frames with near-zero confidence (our telemetry: mean
  confidence 0–4/255 for extended periods, values intermittently frozen while timestamps advanced).
• ~9 seconds before the abort, our app toggled
  AROcclusionManager.requestedEnvironmentDepthMode Disabled → Best (a recovery attempt for the
  degraded stream). The stream recovered (status OK, confidence ~24) and then the ms_depth thread
  aborted.

Tombstone (abridged):

Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 20448 (ms_depth), pid 20247 (com.ghosthunter.app)
esr: 0000000092000006 (Data Abort Exception 0x24)
backtrace:
  #00 pc 0000000000077b70  libc.so (abort+160)
  #01 pc 0000000001331c04  base.apk!libarcore_c.so (offset 0xda8000) (BuildId: 15fc3723f0012d756162123aa00372fd)
  #02 pc 0000000001365524  base.apk!libarcore_c.so
  #03 pc 000000000134b044  base.apk!libarcore_c.so
  #04 pc 0000000001349da0  base.apk!libarcore_c.so
  #05 pc 0000000001dfe34c  base.apk!libarcore_c.so
  ... (all frames in libarcore_c.so through pthread start)

(Full tombstone available on request.)

Expected: degraded depth conditions should degrade output quality (which our app already
handles via confidence gating), not abort the process.

Questions:

1. Is this a known CHECK failure in the motion-stereo depth pipeline under low-confidence input?
2. Is rapid disable/re-enable of environment depth mode a known trigger?
3. Is there a recommended safe way to restart a degraded depth subsystem without a session reset?

Possibly related to the ms_depth crash family in #1371.

[dopamine10]

Cross-referencing from #1769: we (com.netlens, an AR WiFi-survey app) crash on the same device-side binary this report pins down - libarcore_c.so BuildId 15fc3723f0012d756162123aa00372fd, which your device block maps to Google Play Services for AR 1.54.260890093. Thanks for putting the version to the BuildId.

Our signature is a different failure mode from the ms_depth SIGABRT here: SIGSEGV, entirely inside libarcore_c.so on unnamed worker pthreads with zero app frames, across 7 users on budget/mid-range devices (vivo, Motorola, Tecno; Android 15/16). It reproduces on BOTH our ARCore client SDK 1.44 and 1.54 builds (Depth disabled in the 1.44 one), so it is the device-side binary rather than the client SDK or a Depth-specific path. Full stacks + device table are in #1769.

Flagging it here since it is the same 1.54 binary throwing a second, distinct native memory-safety failure - the two may share a root cause in ARCore 1.54's native peer-object lifetime handling.