2

When a crash gets uploaded to the firebase dashboard it always shows the message Upload symbol file to symbolicate future stack traces for UUID *******. However I did make sure that the symbol files got uploaded by looking in the Symbol Files tab. Something I noticed though was that the symbol files had a different UUID then what the message on the crash said. What might I be doing wrong here?

Something strange is that it seems like neither the UUID in uploaded symbol files nor in the message mentioned above is correct. I get a third UUID when I check it up locally by following this guide (basically running find . -iname *.app in ~/Library/Developer/CoreSimulator/Devices/).

I first got this issue in our app using swift 2 and xcode 7. However I also gets the same issue using a new firebase app (ios sdk v3.8) and a minimal xcode 8 project with swift 3 that is setup exactly as advised in the docs.

// AppDelegate.swift
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
    FIRApp.configure()
    return true
}

// ViewController.swift
override func viewDidLoad() {
    super.viewDidLoad()
    FIRCrashMessage("A test message")
    fatalError()
}

// Run script in Build Phases that uploads symbol files
GOOGLE_APP_ID=our_google_app_id
"${PODS_ROOT}"/FirebaseCrash/upload-sym "serviceaccount.json"

// Podfile (using latest versions as of 2017-05-12, v3.17.0)
pod 'Firebase/Core'
pod 'Firebase/Crash'
Community
  • 1
  • 1
Simon Bengtsson
  • 7,573
  • 3
  • 58
  • 87
  • have you found a fix yet? I'm suffering from same problem and can not figure it out. – Shayan C Oct 26 '16 at 17:11
  • Nope, still don't get detailed crash reports. Would love to know if anyone is getting it with swift. – Simon Bengtsson Oct 26 '16 at 17:52
  • I've got the same problem. There are DSYM files that have been uploaded. But it never matches the UUID in the crash log. – lucasl Dec 19 '16 at 11:46
  • Really strange. So this might indeed be a bug in firebase then. Maybe support for swift is not working completely yet despite what they are stating. – Simon Bengtsson Dec 19 '16 at 12:47
  • Hey Guys, I had a similar question, haven't confirmed this yet but it seems that the issue is related to the Firebase Console asking for the dSYM files for some of your library binaries. As long as you can read your crash reports I think you should be ok. Once I get confirmation I will answer this question and my own. You can see my question and the comment from the Google software engineer here: http://stackoverflow.com/questions/41132311/firebase-crash-console-asking-for-uuid-of-a-build-that-does-not-exist – Josh Dec 19 '16 at 19:35
  • 1
    So the most likely issue is that Apple is regenerating the symbol files when bitcode build setting is on (on by default). There is now a section about it in the [docs](https://firebase.google.com/docs/crash/ios#bitcode_support). I have yet to succeed in uploading downloaded bitcode symbol files with the batch-upload script. I will test to disable bitcode in the next release of our app to see if that works. – Simon Bengtsson Jun 08 '17 at 22:48
  • Disabling bitcode and uploading as explained in the docs works fine! – Simon Bengtsson Aug 17 '17 at 08:35

1 Answers1

0

I think maybe the path of "ServiceAccount.json" is wrong, please check again. It should be

"${PODS_ROOT}"/FirebaseCrash/upload-sym "/Path/To/ServiceAccount.json"

And you need also to add this in the script.

rm $HOME/Library/Preferences/com.google.SymbolUpload*

shilei365
  • 223
  • 2
  • 13
  • For me it worked after disabling bitcode and I stopped looking into it after that. But I saw that they added a section about bitcode in the docs so maybe it works with that too now. – Simon Bengtsson Sep 12 '17 at 12:53
  • yes, u can disable bitcode but it is another question. – shilei365 Sep 13 '17 at 14:23