This post is from the WWDC26 Power & Performance Q&A.
Hi! I have a few questions about the lifecycle and capabilities of the Crash Reporter Extension.
- Besides using the
corpsePortto inspect the crashed process through Mach APIs, is it safe/supported/recommended for the extension to access files in a shared App Group container? Are there any caveats or exceptions we should be aware of, for example around memory-mapped files, file coordination, or filesystem access after the host app has crashed? Shall we use some particular APIs for this kind of shared resource or not? - While debugging the extension, I noticed that when I trigger a crash in the app I am debugging, LLDB does not stop inside the extension (it also ends up stopping the debugging session). However, I can observe that the extension does run, because it writes data into a shared App Group directory related to the crash. Is this expected behavior? Is there a recommended way to debug the Crash Reporter Extension reliably (with lldb, or other way)?
- More generally, I would like to better understand the extension lifecycle:
- When exactly does the extension start running?
- How long can it live after the app crashes?
- Is there a time limit for operating on the corpse process?
- Is the extension subject to resource limits similar to other app extensions, such as memory, disk, CPU, watchdog, or jetsam constraints?
- If the Crash Reporter Extension itself crashes, how can we detect that? Would those crashes appear in Xcode Organizer, or is there another recommended way to observe them?
Any clarification around the supported lifecycle, debugging model, and resource limits would be very useful.