QuincyKit/PLCrashReporter: provide description *be

Question

I'm using QuincyKit, which runs on top of PLCrashReporter, to discover production crashes in my iOS app, and to obtain logs. Sometimes, it'd tremendously help me debug if I had some variables from several call stack levels above the crash point. Like, what record ID did it crash on, if the record processing code is many levels of nesting deep.

The question is - is there a way to provide some kind of context string that gets inserted into a crash log as description at generation time? I'd set it upon entry into a call stack for a record, I'd clear it upon exit. Better if it's non-persistent (i. e. in memory) - writing to the nonvolatile storage all the time would be taxing on the battery, I'm afraid.

Answer 1

Found a limited workaround. I use a shared memory block with a name that's derived from bundle ID to store the context string. The block is cleared on proper shutdown. Then I override -crashReportDescription in my Quincy delegate so that it provides the shared memory contents, if any, as description. It is only nonempty if the last app shutdown was a crash.

There are obviously flaws with this approach. If they, say, restart the device between the crash and the next app startup, the shared memory info is lost.

EDIT: in the first version of the design, I used a private, named UIPasteboard instead of shared memory. That turned out to be quite a performance hit. Shared memory is orders of magnitude faster.

EDIT2: but then they broke shared memory in iOS 7, so UIPasteboard is back. Bummer.

EDIT3: found another approach, less elegant but it works in iOS 7. I store my context string in a plain static memory block. I place a custom crash handler within PLCrashReporter with [[PLCrashReporter sharedReporter] setCrashCallbacks:]. In the handler, I write out said context (if any) to a file. On app startup, I read said file, and provide the contents (if any) in -crashReportDescription. Go away, UIPasteboard.

Answer 2

No, but the feature was proposed over 2 years ago and there's a patch.

I'd actually prefer a version that allowed logging the contents of a ring buffer (which you could efficiently log messages to!), which seems potentially much more useful.