3

I am trying to get crash reports working on my ios app. I am getting an error message in the Firebase Crash dashboard that says

Upload symbol file to symbolicate future stack traces for UUID 69696969-7F8H-567E-1ABCD-FAKEID123

I have checked every binary on my machine, and not a single one of them has this UUID. So where is this UUID coming from? I put a fake one in the example above obviously, but how can Firebase be asking for this UUID if it doesn't exist?

Note that this is a test crash. I am calling

FIRCrashMessage("Hey man, you crashed.")
fatalError() 

in my app. The build is one I've downloaded from iTunes connect via TestFlight. Is Apple creating a binary that I don't have a dSYM file for? I have bitcode disabled.

I also verified that the run script is working. If I click "Symbol Files", to the right of "Dashboard" on the Firebase Crash Reporting tab I have lots of dSYM files uploaded to the Firebase Crash service, but none match the UUID of the binary I've downloaded from TestFlight.

Josh
  • 2,547
  • 3
  • 13
  • 28
  • It's likely prompting for symbols associated with iOS libraries, rather than libraries belonging to your app. libswiftCore is a pretty good candidate for what's missing. What device, swift version, and iOS version is associated with the crash? And which version of XCode are you using? – Keith Simmons Dec 15 '16 at 22:48
  • Its an iPhone 6, Swift 3, and iOS version 10.2. Xcode is version 8.2. So are you saying that its asking for the dSYM for the Facebook SDK binaries or the Firebase SDK binaries, as an example? – Josh Dec 17 '16 at 00:03
  • Seems to be similar to this one (sadly no solution either): http://stackoverflow.com/questions/40204969/wrong-symbol-files-uploaded-by-firebase-crash-reporting – lucasl Dec 19 '16 at 16:38
  • It could be the Facebook SDK if you are dynamically linking it to your project. This isn't possible with Firebase at the moment since it's only distributed as a static .a library. But most likely, it's the swift runtime itself (libswiftcore.dylib). – Keith Simmons Dec 20 '16 at 23:59
  • Hey @KeithSimmons, thanks for taking the time to answer here. I'm not really sure how to handle this though. How could this be fixed? Or is this something within Firebase? – lucasl Dec 28 '16 at 15:57
  • The easiest way would be posting the actual UUID. Then I can confirm the source. UUIDs are regenerated every time you rebuild a binary, so if you're concerned this UUID is sensitive, you can generate a crash on a fresh build that has a brand new UUID. – Keith Simmons Jan 03 '17 at 18:56

0 Answers0