Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Partially symbolicated crash logs on IOS SDK Development #277

Closed
6 tasks
caglaruslu opened this issue Jan 3, 2019 · 11 comments
Closed
6 tasks

Partially symbolicated crash logs on IOS SDK Development #277

caglaruslu opened this issue Jan 3, 2019 · 11 comments
Assignees

Comments

@caglaruslu
Copy link

Platform:

  • iOS
  • tvOS
  • MacOS
  • watchOS

Swift:

  • Yes -> 4.2?
  • No

sentry-cocoa installed with:

  • CocoaPods
  • Carthage
  • Manually

Version of sentry-cocoa:
4.1.0


I have following issue:

I develop an IOS SDK, which developers can implement it to their apps as a framework.

The related DSYM file (produced from my SDK project) is automatically uploaded to Sentry on every build.

But the problem is when someone’s app crashes due to an error on the SDK I’m developing, Sentry returns partially symbolicated crash logs that I can barely understand what has happened and where the crash has occurred.

Is there a way that I can get the fully symbolicated crash logs, without changing the app’s project settings and without uploading anything (app’s DSYM etc.) from the original app. (Since I don’t have the app, I’m only producing the SDK)

My project has the following build settings:

  • Strip Debug Symbols During Copy: No
  • Strip Style: Debugging Symbols
  • Strip Linked Product: No

Steps to reproduce:

  • Step 1: Put a bug in SDK project
  • Step 2: build project and upload DSYM to Sentry
  • Step 3: Generate .framework file and import to an App
  • Step 4: Run the app, make it crash due to the bug
  • Step 5: Check Sentry Dashboard

Actual result:

  • Crash logs are partially symbolicated.
  • 'Optional and required debug information file was missing' error.

Expected result:

  • Crash logs are fully symbolicated.
@HazAT
Copy link
Member

HazAT commented Jan 3, 2019

If I understood the issue correctly, there is no way of getting a fully symbolicated crash log for this scenario.
We are only able to symbolicate frames where the user uploaded the dSYMs. I guess you probably see symbolicated frames for your framework (where you uploaded the dSYMs) but not for the app.

@HazAT HazAT self-assigned this Jan 3, 2019
@caglaruslu
Copy link
Author

Thank you for your quick response :)
I only want that part (the part from where I provide dSYM) to be fully symbolicated.
Sentry is integrated to the SDK that I'm working on and dSYM is uploaded from that SDK.
And my SDK is integrated to an another app, which another developer is working on.
If my SDK project causes an app to be crashed, I need to get what part of SDK is wrong, which line of the SDK caused an error etc.

Let me give you an example.
This is what Sentry shows me:
screen shot 2019-01-03 at 14 30 11

All these methods on the screenshot are belong to the SDK, as I want. But the problem is they are partially symbolicated.

@HazAT
Copy link
Member

HazAT commented Jan 3, 2019

Quick question, are you using sentry.io or self hosted?
If running on sentry.io can you please paste the link to the issue.

What you see here are mangled frames, if this is on sentry.io this is a bug.

@caglaruslu
Copy link
Author

I'm using sentry.io
If I understand you correctly, thats the link for a crash related to the screenshot I sent:
https://sentry.io/drive-buddy-6o/dev-ios/issues/795712671/?query=is%3Aunresolved

But I get this problem for all issues on my dashboard.

@HazAT
Copy link
Member

HazAT commented Jan 3, 2019

Thanks for the link.

Quickly discussed this with @jan-auer we found out that we only demangle if we also find the related uploaded symbols (for this special case we don't need the symbols since it's a dev build and symbols are not stripped).

So right now this is a limitation on sentry.io we may change this in the future but right now we won't since it's a bigger change in our processing pipeline.

Workaround: upload symbols :/

(You can find uploaded symbols here: https://sentry.io/settings/drive-buddy-6o/dev-ios/debug-symbols/)

@caglaruslu
Copy link
Author

caglaruslu commented Jan 3, 2019

I don't understand what the problem is, what the limitation of Sentry is and why we don't need dSYM's for this special case.
After the SDK finishes building, Xcode shows up a notification that the Symbols successfully uploaded to Sentry. But at the link you sent there isn't any symbols.
I'm confused 😄

screen shot 2019-01-03 at 15 53 35

@HazAT
Copy link
Member

HazAT commented Jan 3, 2019

Sorry 😅
Can you make sure that
1.:
You did this: https://docs.sentry.io/clients/cocoa/dsym/#upload-symbols-with-sentry-cli

Espacially this part:

For this you need to st the DEBUG_INFORMATION_FORMAT to be DWARF with dSYM File

and 2.:

That the parameters of

export SENTRY_ORG=
export SENTRY_PROJECT=
export SENTRY_AUTH_TOKEN=

are the correct ones.


While writing this I was checking your other projects and you uploaded all the symbols to the wrong project, see: https://sentry.io/settings/drive-buddy-6o/dev-analyzer/debug-symbols/

You have to change export SENTRY_PROJECT=dev-ios, then it should work.

@caglaruslu
Copy link
Author

Thank you so much!
But now it seems like crashes cannot be detected. At least this issue happens for my test device, I put a flag into somewhere in SDK and crashed the app, then the crash log did not appear on the dev-ios dashboard. I need to look deeper on this issue. I'll test it with my users and share the result in couple days.
Thanks again 😄

@HazAT
Copy link
Member

HazAT commented Jan 4, 2019

I'm closing this issue for now, feel free to create a new or reopen this one.

@HazAT HazAT closed this as completed Jan 4, 2019
@caglaruslu
Copy link
Author

This was the issue, now I can get the fully symbolicated logs.
Thanks!

@tuanmai
Copy link

tuanmai commented Mar 27, 2019

@caglaruslu I ran into a similar issue when using react native, how did you fix it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants