Include custom info in crash report

[GoogleCodeExporter]

It would be nice if one could include custom info (simple NSString) in a crash 
report.

I thought it might be possible to do this by adding it to 
plcrash_log_writer_init(). However in my 
particular use case it would be nice to update the info at least once after a 
state change in the 
application. Even though that state change occurs near the beginning of the 
application life cycle I 
don't want to wait that long to turn on the crash reporting.

I'm willing to implement with approved direction if felt it would be a nice 
addition. Any thoughts or 
ideas on this are welcomed.

Original issue reported on code.google.com by mledf...@gmail.com on 24 Feb 2010 at 5:07

[GoogleCodeExporter]

I think this is a valuable feature to add. My suggestion would be the addition 
of an 
optional "application_data" byte field to the ApplicationInfo protobuf message, 
within 
which API clients may place arbitrary application-specific binary (or string) 
data.

http://code.google.com/p/plcrashreporter/source/browse/trunk/Resources/crash_r
eport.proto#82.

In terms of API, PLCrashReporter (and the underlying plcrash_log_writer) could 
be 
extended to accept an arbitrary byte stream at any time.

ie:
-[PLCrashReporter setApplicationData: (NSData *) data]
plcrash_log_writer_set_app_data(void *data, size_t len);

Original comment by landon.j.fuller@gmail.com on 25 Feb 2010 at 5:47

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by landon.j.fuller@gmail.com on 24 Jun 2010 at 5:23

• Changed state: Started

[GoogleCodeExporter]

Hi Guys. I'd like to second the concept of embedding custom info into the crash 
report. For example, I'm seeing a number of crashes that I can only replicate 
in the simulator if I first trigger a device memory warning and then do a 
certain series of steps. So, in my use of this feature, I'd want to define a 
flag that would add a bool value to the Crash Report indicating whether or not 
a memory warning had occurred at some point between app start up and the crash.

Any chance this information is hiding before my eyes and I just can't recognize 
it in the call stack? Every once and awhile, I'll see a specific 
didReceiveMemoryWarning method call in the stack, but in other cases, there's 
nothing to indicate a DMW, but its the only way I can recreate the bug.

Hope that wasn't too confusing. 

Thanks,

Bob

Original comment by chronics...@gmail.com on 18 Sep 2010 at 9:38

[GoogleCodeExporter]

Issue 20 has been merged into this issue.

Original comment by landon.j.fuller@gmail.com on 13 Sep 2011 at 9:18

[GoogleCodeExporter]

I've taken a crack at implementing support for application-specific data.  My 
patch is attached.

The approach is nearly identical to Landon's suggested implementation, and I 
think it integrates well with the rest of the PLCrashReporter code.

I also have a public fork of the code (including this patch in the 'appdata' 
branch) on GitHub:

https://github.com/booyah/PLCrashReporter/compare/master...appdata

One thought that might warrant further discussion: I implemented this using 
NSData/bytes, which is very flexible. However, I imagine many people will just 
stuff string data in there, so it might be nice to consider adding some level 
of support for this new field to PLCrashReportTextFormatter. For now, I'm just 
dealing with this field externally.

Original comment by jon.par...@booyah.com on 28 Dec 2011 at 1:20

Attachments:

• application-data.patch

[GoogleCodeExporter]

I managed to use your patch, but I cannot find where data set with 
setApplicationData: method are written. Should data appear on the decode crash 
report? Or somewhere else? Any explanation would be appreciated.

Original comment by nicola.m...@gmail.com on 25 Jul 2012 at 11:01

[GoogleCodeExporter]

PS: I've seen that custom application data are not encoded using google 
protobuf, is this a bug or a wanted feature???

Original comment by nicola.m...@gmail.com on 25 Jul 2012 at 2:22

[GoogleCodeExporter]

Please, is there any chance that this patch, or similar functionality, is 
integrated into the trunk? The fork at the link is rather stale.

Original comment by fats...@gmail.com on 26 Aug 2014 at 1:41