Details
-
Type:
Improvement
-
Status: Open
-
Priority:
Trivial
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: 1.4
-
Component/s: Crash Log Writer
-
Labels:None
Description
On iOS and Mac OS X, Apple has defined a set of private mechanisms for applications to vend additional data to the crash reporter:
- __crashreporter_info__
- __DATA,__crash_info (I believe this is Mac OS X only)
We should investigate whether:
- These mechanisms can be used safely from PLCrashReporter; specifically, whether we can rely on any implicit ABI guarantees here, and whether this would introduce reliance on private symbols (which, due to the risk of App Store rejection, is not something we can reasonably do in the mainline project), or
- If there are alternative mechanisms to gather similar or equivalent data.
It's clear that we can safely dereference the data in question, as we have mechanisms for safely extracting/dereferencing potentially invalid data at runtime. The question is whether we can do so while providing useful reliable data and not exposing library integrators to risk.
As a fallback option, exposing the internal APIs required to implement this is on the 2014 roadmap; we combining that with support for writing arbitrary key/value pairs would make this possible to implement externally with relatively little work.
Issue Links
Activity
It definitely is a bit of a strange situation and unfortunately Apple's the only one who could make this clear. I doubt DTS would be willing (or, quite possibly, able) to commit to anything regarding app store policies.
The long-term solution, as you mentioned, is to make PLCrashReporter extendable, but I think the pragmatic short-term answer is a configuration flag (i.e.PLCRASH_FEATURE_APPLE_CRASHREPORTER_INFO). Thoughts?
Based on IRC conversations between Joe and I, we'll be punting on supporting the Apple data for now, and instead will ship support for our own __DATA,__plcrashreporter_annotation__.
Reasoning:
- Since the Apple symbols are SPI, we can't ship references to them in project by default.
- To keep the project testing matrix manageable, wish to avoid variances in the build caused by off-by-default build flags such as PLCRASH_FEATURE_APPLE_CRASHREPORTER_INFO.
Plan going forward:
- We will ship support for our own __DATA,__plcrashreporter_annotation__ in PLCrashReporter 1.3. This is a low-impact change that provides an easy-to-use API for vending additional data to the crash reporter, without introducing any SPI risks.
- We will file a Radar with Apple to request that __DATA,__crashreporter_info__ be documented.
- With the features we currently have slated for 1.3 and 1.4 deployed, we will revisit implementing support for collecting the Apple data safely and externally to PLCrashReporter as a collector plugin.
Here is a patch that implements the feature as discussed in the comments.
Thanks! The patch has been applied in the feature branch for this bug (see the side bar for JIRA's automatic link), along with some minor style/naming tweaks on my part.
I also will likely have some minor tweaks to the data format and constants before I pull the merge trigger; I'll keep this bug up-to-date, but if you're relying on any of this externally and changes might cause you an issue, let me know.
Added an issue link to Alastair Houghton's write-up of __DATA,__crash_info and __crashreporter_info__
Here's a super rough proof of concept.