Why iOS CoreMotion Crashes on QQ: Debugging Misaligned Address Errors

Investigation Overview

The latest QQ mobile version started reporting a large number of crashes originating from CoreMotion. The stack trace shows an unexpected function name CLStartStopAdvertisingBeacon + 175940, which indicates the address actually belongs to a different function.

The exception code is BUS_ADRALN at 0x006575716572205d, meaning an unaligned address was accessed. The PC and x8 registers both point to this misaligned address, suggesting a corrupted function pointer.

Because the crash occurs on a 64‑bit device running iOS 10.3.1, the exact address of the offending instruction varies due to ASLR. By extracting the load address of the CoreMotion framework from the crash’s Binary Images section (e.g., 0x199543000) and subtracting it from the top‑stack address ( 0x00000001995ab62c), we obtain an offset of 0x6862c. Adding this offset to the current load address on the test device ( 0x00000001985cb000) yields the real address 0x19863362c.

Using lldb on the device: (lldb) image list we confirm the CoreMotion load address and then look up the symbol: (lldb) image lookup -a 0x19863362c The lookup returns an unnamed symbol, indicating the symbol was stripped. Setting a breakpoint at the address: (lldb) br set -a 0x19863362c shows the breakpoint being hit when entering QQ’s “Friend Feed” page. The preceding instruction is blr x8, which branches to the address stored in x8. If x8 is corrupted, the CPU triggers the BUS_ADRALN fault.

Further analysis reveals that the crash is triggered by the use of CMMotionManager inside UIAccelerometer. The two view controllers where the crash appears ( TBStoryViewController and MQZoneVideoRecordViewController) do not directly reference CMMotionManager, suggesting an indirect usage.

By setting a regular‑expression breakpoint on all CMMotionManager methods: (lldb) br set -r "CMMotionManager" the breakpoint cannot be set because the symbols are stripped. Using Frida to trace Objective‑C calls:

frida-trace -U -f re.frida.Gadget -m "-[CMMotionManager *]"

reveals that UIAccelerometer accesses CMMotionManager via its instance variable. Inspection of the runtime header confirms that UIAccelerometer holds a CMMotionManager instance.

The implementation of [UIAccelerometer sharedAccelerometer] and -[UIAccelerometer _motionManager] lacks any locking. When these methods are called from multiple threads, the singleton and the lazy‑initialized _motionManager can be overwritten and released, leading to a dangling pointer.

Breakpoints on both methods show they are invoked from different threads almost simultaneously, confirming the race condition.

The root cause was a developer moving the accelerometer start/stop calls to a global concurrent queue via dispatch_async, while the callbacks still execute on the main thread. This caused concurrent access to the singleton.

The final fix is to ensure all UIAccelerometer operations, including the creation and use of its CMMotionManager, run on the main thread.

Summary

Debugging a CoreMotion crash in QQ involved analyzing crash logs, calculating ASLR‑based offsets, using lldb and Frida to trace hidden symbols, discovering unsafe multithreaded access to UIAccelerometer, and ultimately moving accelerometer handling back to the main thread to prevent misaligned address faults.