Bundled DSYMs only symbolicate the main target

[fjcaetano]

Thank you very much for this tool! It's much simpler to use than manually symbolicating each frame by hand!

I'm having an issue when trying to use a bundled DSYM file. My application has multiple targets where each generate their own DSYM that is bundled in a "master" DSYM. When I try and symbolicate a crash, MacSymbolicator does replace the symbols for the main target (application), but not for the embedded frameworks.

I've tried manually using the DSYMs for each target, but the app shows a warning saying UUID mismatch (which makes sense since this DSYM wouldn't have the same UUID as the main application.

It seems to me MacSymbolicator should also try and match the DSYM's UUID against the Embedded Binaries section in the crash log.

[inket]

Thanks for reporting this! I'll have to look at it this weekend.

[inket]

I created a sample project with multiple targets and when it's built for release via Build > Archive it results in multiple dSYM files under the dSYMs directory of the .xcarchive.

If I'm understanding correctly at this step you only have one dSYM file that contains all the symbols?

It's important to have a project that can replicate the exact same scenario so I can add it to the tests and work towards the solution from there.

Thanks

[fjcaetano]

I'm creating release builds using Fastlane so that might be the reason why they're getting bundled. I'll try putting up an example project for you

[paulz]

thank you for the great app!

we have the same issue on our project built with Xcode. we only get main target symbols and even when we select framework dSYM app says "UUID mismatch" and does not add symbols from our framework.

let me know if you need an example project

[fjcaetano]

It's possible that this is a Fastlane issue. Archiving using Xcode indeed does yield separate .dSYM bundles, but when using the build_mac_app action from Fastlane, it packages all of them in a single .dSYM and compresses it.

This zip contains a project with a reproducible example. Run bundler to install fastlane and then the archive lane and it will build the app for release and generate a zip with the dSYMs:

$ bundle
$ bundle exec fastlane archive

DSYM Example.zip

[paulz]

yes, looks like Fastlane does bundle dSYMs differently. We are not using fastlane. Could you point us in the direction where we can make it work with Xcode without fastlane?

[inket]

@fjcaetano Thanks for making the example project! I was able to create the bundled dSYM.
@paulz It seems that there are 2 issues that have been uncovered here, so I'll try to summarize it.

Main issue:

• For apps with multiple targets, Xcode generates a dSYM for every target
• MacSymbolicator was not designed for this as I was not aware of this case

Plan for dealing with multiple-target apps/crashes:

• The app will have to be redesigned to display a list of UUIDs on the right side and allow users to provide multiple dSYMs.
• The app will also have to be refactored a bit to allow for detecting multiple targets in the crash file, finding a matching dSYM for each one, then symbolicating using those dSYMs

Secondary issue:

• Fastlane's archive action packages multiple dSYMs into one folder that has the suffix ".dSYM", this causes it to be recognized as a "dSYM" even though it doesn't have the typical dSYM structure.

Plan for dealing with the Fastlane issue:

• Correctly detect this format (embedded dSYMs) and allow drag & drop to automatically add all those nested dSYMs.

I will work on this soon since it's a major issue but please be patient 😊

[inket]

This issue should be fixed now! Make sure to grab the latest version (direct link) and tell me how it's working for you.

(Somehow auto-updates aren't working so I'm looking into it)

[fjcaetano]

That's working beautifully! Thank you! Feel free to close this issue if you want to