Missing (or invalid) dSYMs | Apple Developer Forums

Developer Forums

Hi,

We are using Firebase Crashlytics to collect crashes from our app. Firebase Crashlytics says that the dSYM is missing to process crashes for the recent two versions of our app. We have recently not changed anything in our app distribution process (it is based on CI/CD). For the non-product change, we moved one of our internal frameworks to be managed by SPM (previously Carthage).

In build settings, we have set :

Debug information format: DWARF with dSYM Files
Enable bitcode: Yes

Because of the latter, we manually download all dSYMs from the AppStoreConnect page and upload them to the Firebase Crashlytics for each new version.

I've double-checked the UUID's and the one mentioned by Firebase is missing in the downloaded (from the AppStoreConnect) zip file. The zip file contains dSYM for our app but with a different UUID.

Is there anything I can do to verify that generated dSYMs have the correct UUID?

Not sure if this is related, but when I try to download crashes via Xcode Organiser, I got an error:

Unable to download crash information.

An error occurred preventing Xcode from downloading updated crash information. The value “2021-07-27T00:00:00Z” is invalid. Please try again later.

15k

Posted by

MatKuznik

Reply

Accepted Reply

It looks like someone (Apple or Firebase) has fixed the issue. We can see crashes reports for the recent release. Can anyone confirm?

Posted by

MatKuznik

Yep, it's working fine for us as well. A build we had uploaded on 30th Aug 2021, had the dsym UUID being correctly generated.

Xcode organiser also now works properly for builds after 30th Aug 2021.

Old builds which were affected still don't work on xcode organiser. For old builds we are patching the dsym using one of the blog posts linked above, and we are able to symbolicate crashes for them on Instabug.

—
asif.mohd_go

Replies

We've been experiencing the same problem. Some UUIDs are completely missing and crashes can't be symbolicated. Problem started happening about few weeks ago

Posted by

dave.carousell

Seeing the same issue. Is this a known issue on ATC side?

Posted by

vijaytholpadi

Seeing the same issue. We started seeing this for a build which we uploaded to Appstore connect on July 27th 2021. Ever since then all of our bitcode enabled builds uploaded to appstore connect do not have matching UUIDs between the crashes reported and the dsyms downloaded from appstore connect.

Even xcode organiser is unable to symbolicate these crash logs. This issue seems to be happening for app targets and not the extension targets such as Intent Service extensions. The app extension crashes appear symbolicated on xcode organiser.

If it helps our Compressed File size on appstore connect is 274MB.

Posted by

asif.mohd_go

We're also seeing the same issue here. It was still working on July 20th for our last build, but the latest build uploaded on the August 4th 2021 did not have matching UUIDs. Is this being looked at? It's quite important for us to be able to upload the matching dsym files to Firebase Crashlytics.

Posted by

rholliger

Same here for the last two weeks

Posted by

juliensechaud

Hi all.

I’ve got answers from Apple to Radar. Apple says that this is an issue on the Firebase Crashlytics. @asif.mohd_go mentioned that Xcode Organiser also doesn’t work for him.

Could you confirm you are using Firebase Crashlytics or some other services?

Thanks in advance :)

Posted by

MatKuznik

Trying to symbolicate manually some crashlog we can see that UUIDs from Crash log and UUIDs from AppStoreConnect zip file differ. Moreover, as mentioned, Xcode Organiser seems neither to be able to symbolicate. It clearly seems not to be firebase related but Apple related.

Could you provide us the radar link please ?

—
oizhef
It's definitely not issue with Firebase as Xcode Organizer couldn't symbolicate crashes either

—
dave.carousell
Hi @oizhef. Unfortunately, AFAIK, radars are not public. Do you know how I can download crash logs from the AppStoreConnnect?

—
MatKuznik

We are using Instabug, and while we do have some Firebase pods, we are not using FirebaseCrashlytics and do not have it integrated.

Another thing to note is that we haven't really changed any dependencies between the last release where we were getting symbolicated logs and the release in which we are not getting symbolicated logs. It was a patch release with minimal code change and no build setting changes.

These are the firebase pod versions from our podfile

pod 'Firebase', '7.7.0'
pod 'FirebaseRemoteConfig', '7.7.0'
pod 'FirebasePerformance', '7.7.0'
pod 'FirebaseDynamicLinks', '7.7.0'

Posted by

asif.mohd_go

Seeing the same issue - using firebase crashlytics

Posted by

000022

Hi all. We're also seeing the same issue here. Even xcode organiser is unable to symbolicate these crash logs.

Posted by

andresFerCruz

Same issue here - missing dsym on crashlytics, dsyms downloaded from apple, nothing really changed in the app and the issue started a few weeks ago

Posted by

marcinrg

Same issue overthere

Dsyms are missing in the appstore connect archive and it definitly can't be a firebase issue.

Posted by

BlaBlaCarmouze

Managed to symbolicate back !!

Following this great article about "cooking" the dSyms https://medium.com/geekculture/how-to-fix-the-missing-dsyms-on-firebase-crashlytics-5f36d9db51d9

Works on both local symbolicate and on Firebase

Posted by

oizhef

Thanks for this tip. I was thinking about something similar but didn’t know how to do that. This, of course, does not solve the issue, it is rather the workaround than a solution and if it is true it can be a proof that issue should be fixed by Apple 🤔

—
MatKuznik

Same issue here. It seems as if appstoreconnect currently attributes incorrect UUIDs to dsyms generated from bitcode enabled build archives.

One way to solve this (and the only one I know of) is to rename the internal UUID of the dsym that corresponds to the binary image of the stack frame that isn't symbolicated. In most cases this is your app's binary image.

What you can do is either manually rename it using the already mentioned excellent article on medium, or automatically using the following tool: https://github.com/schmittsfn/dsymrename

You have to be absolutely sure, however, that the dsym you are renaming corresponds to the build Crashlytics is requesting (for bitcode builds these are the dsyms generated on appstoreconnect)! Failure to do so will most likely lead to the warning on Crashlytics being silenced and the stack frame being unintelligible.

Posted by

sschmitt

Same here. We are waiting for the solution.

Posted by

czenci

It looks like someone (Apple or Firebase) has fixed the issue. We can see crashes reports for the recent release. Can anyone confirm?

Posted by

MatKuznik

Yep, it's working fine for us as well. A build we had uploaded on 30th Aug 2021, had the dsym UUID being correctly generated.

Xcode organiser also now works properly for builds after 30th Aug 2021.

Old builds which were affected still don't work on xcode organiser. For old builds we are patching the dsym using one of the blog posts linked above, and we are able to symbolicate crashes for them on Instabug.

—
asif.mohd_go