Investigating an Intermittent SIGBUS Crash in iOS Applications
Intermittent crashes in production often require controlled fault isolation when logs and local testing fail to identify the issue. A lower overall crash rate does not guarantee that the root cause is resolved, as unrelated changes can alter the timing of concurrency defects.
In a recent investigation, a SIGBUS signal indicated an invalid memory access in a large-scale consumer iOS application. The crash affected only a subset of executions and appeared unpredictably, prompting a focused investigation and expedited hotfix.
Despite efforts from developers and QA engineers, the crash could not be consistently reproduced. The SIGBUS report pointed to attributed string processing but did not identify a specific line in the Swift code. This left a wide search area, considering factors like object lifetime, SwiftUI view model ownership, and unsynchronized work.
The investigation began with standard checks, including enabling Zombie Objects and reviewing ownership around the affected screens. Defensive improvements were made, tightening observable object ownership and clarifying synchronization. Although these changes reduced the overall crash rate, the original crash signature persisted.
The initial improvements were misleading; while the aggregate crash rate decreased, it did not prove causation. Timing-sensitive failures can become less frequent without removing the underlying defect. The investigation window was narrowing, and a breakthrough came when a QA engineer discovered she could intermittently reproduce the crash.
This reproducible failure transformed the investigation, allowing for practical testing. Each experimental build was tested on the device, and the loop of changing one area, building an IPA, and testing continued. The investigation also included discussions in developer communities, although proprietary information could not be shared.
Systematic fault isolation was employed, changing the focus from suspicious code to identifying which code was essential for the crash to occur. This process narrowed the problem to one operation: converting HTML data into an attributed string.
The affected flow involved displaying a static disclosure section formatted as HTML, which included interactive elements. The critical issue was that the HTML-to-attributed-string conversion could be invoked from an asynchronous path without guaranteeing main-thread execution, violating Foundation’s threading constraint.
Timing-dependent defects can survive many successful executions, explaining why the crash appeared random. Changes in lifecycle handling and synchronization affected timing but did not eliminate the unsupported execution context.
The immediate fix involved performing the HTML conversion on the main actor. A shared helper was introduced to enforce the execution requirement as part of the API, reducing duplication and centralizing the Foundation dependency.
After implementing the fix, the QA engineer tested the flow on the previously problematic device, and the failure no longer appeared. Additional testing confirmed the fix across related views, and production monitoring showed a significant reduction in the targeted crash.
The investigation highlighted the importance of creating new evidence when existing evidence is incomplete. A reproducible failure was more valuable than a list of plausible code changes, allowing for clear hypothesis testing. The incident also underscored the need to evaluate framework abstractions carefully, as Swift initializers may hide unsafe behaviors inherited from other frameworks.
The final code change was small, but the investigation required navigating incomplete crash information, misleading early improvements, and time pressure. The successful identification of the root cause and implementation of a fix not only resolved the immediate issue but also made future occurrences less likely.
Source: InfoQ