[tasks-vision] HandLandmarker SIGILL/ILL_ILLOPC at rdsvl (Armv9 SME) on Apple-Silicon-hosted ARM64 Android emulator — regression introduced between 0.10.29 and 0.10.33, still present in 0.10.35

Have I written custom code (as opposed to using a stock example script provided in MediaPipe)

No — reproduces in your own examples/hand_landmarker/android sample with a single-line tasks-vision dependency bump. See "Standalone code/steps" below.

OS Platform and Distribution

Android 16 emulator: sdk_gphone64_arm64 / emu64a / build BE4B.251210.005, arm64-v8a, 4 KB page kernel (6.12.38-android16-5-...-4k). AVD Medium_Phone_API_36.1. Host: Apple M4 Pro (confirmed via the AVD's GLES translator banner "Apple M4 Pro").

Mobile device if the issue happens on mobile device

N/A — Android Emulator only. Suspect physical handsets are unaffected because their HWCAP doesn't advertise CPU features the silicon can't actually execute.

Browser and version if the issue happens on browser

No response

Programming Language and version

Kotlin / Android (the official examples/hand_landmarker/android sample).

MediaPipe version

Bazel version

No response

Solution

HandLandmarker. Reproduces with RunningMode.IMAGE, RunningMode.VIDEO, and RunningMode.LIVE_STREAM. Reproduces with explicit Delegate.CPU and with implicit default. Reproduces with numHands=1 and numHands=2. Model: hand_landmarker.task float16, SHA-256 fbc2a30080c3c557093b5ddfc334698132eb341044ccee322ccf8bcf3607cde1 (the canonical Google-hosted model at https://storage.googleapis.com/mediapipe-models/hand_landmarker/hand_landmarker/float16/1/hand_landmarker.task).

Android Studio, NDK, SDK versions (if issue is related to building in Android environment)

AVD Medium_Phone_API_36.1 running Android 16 (API 36), system-image system-images/android-36.1/google_apis_playstore/arm64-v8a/, host running Android Studio's bundled emulator on an Apple M4 Pro Mac.

Xcode & Tulsi version (if issue is related to building for iOS)

No response

Describe the actual behavior

Native SIGILL / ILL_ILLOPC on the drishti/<tid> thread within ~9 ms of:

I/tflite: Created TensorFlow Lite XNNPACK delegate for CPU
I/tflite: Replacing 272 out of 272 node(s) with delegate (TfLiteXNNPackDelegate) node

The process is killed by the kernel before the camera can deliver a frame. Process uptime at crash: 1–2 s. Reproducible on every cold launch.

Disassembling the faulting PC (0x98d434 in libmediapipe_tasks_jni.so, BuildId 39b4635fe57f580f6ab38367ec45804a for 0.10.33; the offset shifts slightly in 0.10.35 but the instruction is the same):

98d428: d65f03c0     ret
98d42c: 00000000     udf  #0x0
98d430: d65f03c0     ret
98d434: 04bf5820     rdsvl x0, #0x1     ← traps with SIGILL/ILL_ILLOPC
98d438: d65f03c0     ret

RDSVL (Read Streaming Vector Length) is an Armv9 SME instruction. The surrounding ret / udf / rdsvl / ret pattern is a hand-coded CPU-feature dispatch table — the SME branch was taken based on HWCAP, rdsvl was issued, and the emulated core trapped.

Describe the expected behaviour

XNNPACK / TFLite CPU dispatcher should not select an SME ukernel on a CPU that cannot actually execute SME instructions, regardless of what HWCAP advertises. Either probe before dispatch, or expose a disable-SME flag.

Why this only reproduces on the emulator

The AVD's /proc/cpuinfo advertises sme2 and nine SME sub-features (smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32 sme2 smei16i32 smebi32i32), inherited from the Apple M4 host. But /proc/sys/abi exposes only cp15_barrier, swp, tagged_addr_disabled — no sve_default_vector_length. The CPU identity in /proc/cpuinfo is the QEMU/HVF stub (implementer 0x61 part 0x000 variant 0x0).

So HWCAP says "I have SME2", but the guest kernel + HVF combination has not actually wired SME up for userspace execution. XNNPACK's one-time pthread_once dispatcher trusts HWCAP, selects the SME ukernel, and the first rdsvl traps.

The root cause is arguably in QEMU/HVF (advertising features it can't back), but the practical mitigation lives in XNNPACK/MediaPipe (probe before trust, or downgrade default).

Standalone code/steps you may have used to try to get what you need

Single-line reproducer in your own sample:

# examples/hand_landmarker/android/app/build.gradle
- implementation 'com.google.mediapipe:tasks-vision:0.10.29'
+ implementation 'com.google.mediapipe:tasks-vision:0.10.35'

Then on an arm64 AVD running on an Apple Silicon Mac:

./gradlew :app:installDebug
adb shell am start -n com.google.mediapipe.examples.handlandmarker/.MainActivity
adb logcat -b crash -d

The app crashes within 1–2 s of launch (no UI interaction required). Reverting the single dependency line restores correct behavior.

Other info / Complete Logs

F/libc:  Fatal signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0x... in tid <tid> (drishti/<tid>)
F/DEBUG: Build fingerprint: 'google/sdk_gphone64_arm64/emu64a:16/BE4B.251210.005/14574095:user/release-keys'
F/DEBUG: signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0x...
F/DEBUG: 26 total frames
F/DEBUG:   #00 pc 000000000098d434  libmediapipe_tasks_jni.so   ← rdsvl
F/DEBUG:   #01 pc 00000000007d0064  libmediapipe_tasks_jni.so
F/DEBUG:   #02 pc 00000000007d0580  libmediapipe_tasks_jni.so
F/DEBUG:   #03 pc 000000000090e174  libmediapipe_tasks_jni.so
F/DEBUG:   #04 pc 0000000000088834  libc.so (pthread_once+148)
F/DEBUG:   #05 pc 000000000090e0f8  libmediapipe_tasks_jni.so
F/DEBUG:   ... 23 frames inside libmediapipe_tasks_jni.so + libc thread-start frames #24-#25 ...
I/Zygote: Process <pid> exited due to signal 4 (Illegal instruction)

Likely introducing version: 0.10.32, whose release notes explicitly say "Update xnnpack version. Use the new xnn_reduce_mean_squared reduction for the RMSNorm." 0.10.29 (the previous version we tested) does not have the SME ukernel in its bundled XNNPACK and runs cleanly on the same AVD.

Suggested mitigation in MediaPipe / XNNPACK

Gate the SME ukernel selection in XNNPACK on something stronger than HWCAP — either a kill(0, 0)-style probe of rdsvl wrapped in sigaction(SIGILL, ...), or a check against /proc/sys/abi/sve_default_vector_length existence. The Apple Silicon Android emulator is a common dev environment and this regression makes the entire tasks-vision library unusable there for at least three consecutive releases (0.10.32, 0.10.33, 0.10.35).