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.
1- … is it safe/supported/recommended for the extension to access files in a shared App Group container?
I don’t see any fundamental problems with that but…
As with any shared files, you have to take steps to ensure consistency. Moreover, using a file lock isn’t a valid approach, because the main app might die while in the lock. Likewise for file coordination. You have to rely on atomic file system operations instead.
2- While debugging the extension …
I haven’t had a chance to play with this yet, but I suspect that this will act like any other appex, in that you have to tell Xcode to debug the appex, not the app. If you want to debug the appex and the app, you need to run both, and then you need to detach from the app after crashing because otherwise LLDB will swallow the crash (in the same way that LLDB-caught crashes don’t generate system crash reports).
If that doesn’t work, lemme know because there are always other options (-:
3- When exactly does the extension start running?
App extensions lifecycles are complicated, and they’re generally not considered API. That is, the system might launch the appex early, or keep it running after it completes, or whatever. Rather than worrying about the process itself, it’s best to focus on its invocation, which in this case means the system calling your processCrashReport(process:) method. Your extension process will be executed from the point where the system calls that routine to the point where that routine returns.
Except there’s a time limit, which I’ll come back to (-:
How long can it live after the app crashes?
That’s not considered part of the API.
Is there a time limit for operating on the corpse process?
Yes. I couldda sworn that was in the docs, but apparently not. Anyway, one of my colleagues discussed it on this thread.
Is the extension subject to resource limits … ?
Yes.
That’s not really a meaningful question because all third-party iOS code is subject to resource limits (-:
If the Crash Reporter Extension itself crashes, how can we detect that?
Your crash reporter extension can’t have its own crash reporter extension. Where would that end? (-:
If your crash reporter extension crashes, those crash reports will show up in the usual places. So, if your app is on the App Store they’ll show up in the Xcode organiser.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"