Loaded DSYM files but crashlog isn't symbolicated

SDKs
1

I had a few crashes in my recent release of iOS apps.

Crashs in Sentry look like:

MyApp    0x00076b0c    <redacted> 
MyApp    0x000a88c4    <redacted> 
MyApp    0x000a8788    <redacted> 
Called from:    UIKit    -[UIViewController _setViewAppearState:isAnimating:]
MyApp    0x00052d44    <redacted>

And I have an error message above the issue:

There was 1 error encountered while processing this event
A required debug symbol file was missing. 
{
  "image_arch": "armv7",
  "image_uuid": "dd49f285-90ab-3cbe-aa09-dc3fc65449ed",
  "message": "None",
  "image_path": "/var/containers/Bundle/Application/B67F0462-B7C1-4DE0-A6D6-65061D3C289A/MyApp.app/MyApp"
}

I found that I haven’t uploaded DSYM (app is using bitcode). So I downloaded dsyms and uploaded them (to Fabric and Sentry). I can see reason of the crash in Fabric but sentry shows me the very same error I pasted above.
And I can clearly see that my app’s DSYM was loaded to Sentry (in Project Settings -> Debug Information Files under my latest release) and that missing image_uuid is there (4th from the end).

UUID	Object	Type	Uploaded	Size
e64c110b-bb0f-324a-a891-3ccae4bf5c00	KSCrash	armv7 (macho)	Nov 20, 2017 1:36:35 PM UTC	518.2 KB	
7cd385f7-9b74-3675-909c-fe6d0ef3d67b	GoogleToolboxForMac	arm64 (macho)	Nov 20, 2017 1:36:35 PM UTC	37.9 KB	
e4b3ac8d-8aca-35d7-984e-81af6a75da77	Alamofire	armv7 (macho)	Nov 20, 2017 1:36:36 PM UTC	686.9 KB	
b049aa49-c742-352c-ae9c-a365e74b45ca	Sentry	arm64 (macho)	Nov 20, 2017 1:36:36 PM UTC	143.2 KB	
a2130b03-16b5-3408-83bd-9f0a65a10626	DynamicBlurView	arm64 (macho)	Nov 20, 2017 1:36:37 PM UTC	91.4 KB	
8cf34a59-79ec-3bdd-b213-e75106c231ed	nanopb	arm64 (macho)	Nov 20, 2017 1:36:37 PM UTC	37.2 KB	
6eac26a3-43a2-3ba5-a588-1e3f47a4cc33	ReachabilitySwift	arm64 (macho)	Nov 20, 2017 1:36:37 PM UTC	75.3 KB	
bac7886c-9bc6-344a-8843-add4d99e9984	KSCrash	arm64 (macho)	Nov 20, 2017 1:36:37 PM UTC	561.7 KB	
0daf8238-c81c-3356-b69b-10b117c8fb1c	MyApp	arm64 (macho)	Nov 20, 2017 1:36:38 PM UTC	2.9 MB	
a967028d-7049-33da-89ab-bf4fdf8e8442	Pantry	armv7 (macho)	Nov 20, 2017 1:36:40 PM UTC	129.4 KB	
f84dbcc8-7356-39f2-a4ba-3536e0a132f8	Pantry	arm64 (macho)	Nov 20, 2017 1:36:40 PM UTC	128.0 KB	
3146260e-8ef2-3d0d-835d-6af797fda275	ReachabilitySwift	armv7 (macho)	Nov 20, 2017 1:36:40 PM UTC	81.6 KB	
98ed9d9e-0f8d-3187-8089-e1324f176c0b	nanopb	armv7 (macho)	Nov 20, 2017 1:36:41 PM UTC	44.1 KB	
289e96ec-ab36-3665-a2d6-89f7f2d15b26	Sentry	armv7 (macho)	Nov 20, 2017 1:36:41 PM UTC	149.0 KB	
dd49f285-90ab-3cbe-aa09-dc3fc65449ed	MyApp	armv7 (macho)	Nov 20, 2017 1:36:42 PM UTC	2.8 MB	
13968181-3622-3373-98d7-c425b3f732c0	DynamicBlurView	armv7 (macho)	Nov 20, 2017 1:36:43 PM UTC	98.1 KB	
102c7b39-6d7f-39f6-845a-21bad4567617	GoogleToolboxForMac	armv7 (macho)	Nov 20, 2017 1:36:44 PM UTC	49.8 KB	
1ef51f54-3de0-3acc-b7af-b1971e5b24da	Alamofire	arm64 (macho)	Nov 20, 2017 1:36:44 PM UTC	738.1 KB

It seems like Sentry doesn’t use freshly loaded DSYM files to re-symbolicate crashes which already happened.

2

Hey,

So there is a feature called reprocessing: (Found under Project Settings > Processing Issues)

25
Screenshot 2017-11-21 09.27.25.png1514×472 50.1 KB

This should be on by default but please check it.
When this is enabled, events with a required dSYM will not be processed until you uploaded the required symbols.

3

It was off (and I’m 100% sure I never touched it). Set to On, thanks.

So, am I right that there is no way to update created issue with uploaded DSYM information? For the current issue that isn’t a problem - as I solved it, but that is huge limitation. Basically I was able to fix the issue only because Crashlytics updates crash information automatically after I uploaded DSYM.
Sentry already detects that symbols are missing. I believe it can go through all issues with missing symbols and update them after symbols are loaded. Or at least to have manual way to refresh crash info for a certain event after symbols are uploaded.

4

So the thing is, we made it on by default sometime back in 2017, at first it was opt in and if your account is older than early 2017 this option will be off.

Sadly, we are not able to re-symbolicate crashes after they are processed without this feature turned on due to our internal immutable event structure.

So you should be safe from now on but old crashes/events can no longer be symbolicated.

5

Just a quick note that I’m in an account that was created just this year, and that option was off by default for me - given the extreme pain that ensues from having a crash but not being able to re-run symbolication after uploading Dsym files, the option should probably be removed and permanently set to on.

Also that settings page claims there are no processing issues while on the page with my application crash I have two reported issues in processing the crash, so that warning seems disconnected from what is really happening with the logs…

1 Like
6

Yep same here. Created the account maybe 2 months ago and it was off.

7

Same problem for me, the Reprocessing option was off by default, account about 3 month old. Stuck with unsymbolicated reports. Please fix this guys.

8

At what time crashes get processed?

I believe the mentioned switch doesn’t do anything: if I had symbols uploaded before crash reached sentry server, everything is fine. If crash reached sentry before symbols uploaded, I see no way to get crashes symbolicated – after uploadyn dSYMs I see crashes unsymbolicated regardless of the switch state.

9

For those looking at this old thread, I thought I’d note that I have a newer (2020) project where reprocessing was not on by default. It looks like this may have changed after @HazAT left his comment.

10

This can make sense for system symbolication failures, but we can no longer generally recommend enabling the feature of reprocessing by holding back events because it affects alerts too negatively. Outside of iOS holding back events causes more problems than it solves I suppose. More info at the bottom of this page: Reprocessing | Sentry Documentation