iOS "Reprocess Crash Report" doesn't update the backtrace

Scribe

Posted on
Apr 14 2016

After uploading the build in question's dSYM using both the sidekick and manual methods, requesting any crash report to be reprocessed fails to update our application's code in the backtrace.

Previously it would update the backtrace lines containing our code with wonderful, at times pinpoint, accuracy to help address the issue.

The build in question was built with Xcode Version 7.3 (7D175).

Jason Fauchelle

Raygun

Posted on
Apr 14 2016

Hi Scribe,

Thanks for mentioning this. We are looking into the issue.

On a side note, where possible, we recommend uploading the dSYM files early on, e.g. before uploading the app to the store. With the dSYM files available when the reports come in, they can be fully symbolicated straight away (no need to reprocess them) and Raygun will be able to use the stack trace info for better grouping.

We will keep you updated on the reprocessing issue.

-Jason Fauchelle

Jason Fauchelle

Raygun

Posted on
Apr 15 2016

Hi Scribe,

The reprocessing issue has been fixed now. When you hit the re-process button for any existing or new error reports, they will get reprocessed as expected.

Thanks again for contacting us about this issue. Let us know any time you have further questions about Raygun.

-Jason Fauchelle

Scribe

Posted on
Apr 16 2016

Hi Jason,

Our code still doesn't seem to appear after reprocessing. Here is an example of what the backtrace still looks like after reprocessing and checking back awhile later:

6   UIKit                               0x2918e447 -[UITableView reloadSections:withRowAnimation:] + 38
7   ScribeMobile                        0x00112815 0xea000 + 165909
8   UIKit                               0x291a3ec7 -[UISearchBar(UISearchBarStatic) _searchFieldEditingChanged] + 142

Step 7 being our application which I expected would be updated with at least the class in question. Let me know if more information is required.

(Am I wrong in remembering that those lines were what reprocessing would update into useful, often pinpoint, information about the backtrace/crash?)

Jason Fauchelle

Raygun

Posted on
Apr 18 2016

Hi Scribe,

Yes, the 'ScribeMobile' lines are the ones that should be giving you useful info. The logs are indicating that the dSYM file for those lines can not be found. It's expecting a dSYM file with the guid: 5C2EC30F-A626-3F4C-80B0-439AF911092F

You can try and find this on your machine by using the following command in a Mac terminal:

mdfind "comapplexcodedsymuuids == 5C2EC30F-A626-3F4C-80B0-439AF911092F"

If it works, it'll print one or more file paths to dSYMs with that guid. Upload one of them to Raygun and try reprocessing again. That guid will be displayed in the "dSYM center" section of "Application settings" of your Raygun app.

Hope that solves the issue!

-Jason Fauchelle

Scribe

Posted on
Apr 19 2016

Hi Jason,

Unfortunately the mdfind did not return any result paths.

I do know that only one archive was made for the version in question, 2.4.2 (12), and the two files generated in the "dSYM center" when it's dSYM is uploaded show UUIDs of:

  • ARMv7: 66d13d48-d400-375c-81b6-cd7ad4d638af
  • ARM64: 9d876426-4e07-3de8-b9de-e1d6e45feaf3.

Jason Fauchelle

Raygun

Posted on
Apr 19 2016

Hi Scribe,

My apologies, the forum formatted the terminal command. Could you please try again with:

mdfind "com_apple_xcode_dsym_uuids == 5C2EC30F-A626-3F4C-80B0-439AF911092F"

This is definitely the guid of the dSYM file being referenced within the crash reports for the version you mentioned. Let me know if you find it now or not.

-Jason Fauchelle

Scribe

Posted on
Apr 19 2016

Hi Jason,

Even with the corrected mdfind command it still failed to result in any results. Let me know if there's anything else we can try from our end.

Jason Fauchelle

Raygun

Posted on
Apr 19 2016

Hi Scribe,

The other possibilities is that you've got bitcode enabled in your app, in which case the dSYM files would need to be downloaded from Apple. Or if not, the dSYM files may have been misplaced, in which case I would recommend building a new archive, deploying to a device, uploading the dSYM(s), cause an exception and see if the problem remains. Make sure to upload all dSYMs within an archive if there's more than one. Let me know how it goes.

-Jason Fauchelle

Scribe

Posted on
Apr 20 2016

Hi Jason,

You found it! The issue was bitcode and the fact that we needed to get the dSYM from iTunesConnect, not the archive. Wow that feels silly not knowing that was the root of the issue.

Thank you so much for all the help getting us to sort out this confusion!

-Scribe

Jason Fauchelle

Raygun

Posted on
Apr 20 2016

No worries Scribe,

Great to hear that you were able to acquire the dSYM files, rather than them being lost.

Let us know any time you have further questions about Raygun.

-Jason Fauchelle

Reply