-
-
Notifications
You must be signed in to change notification settings - Fork 435
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
Minified exception class name is not resolved into the original class name #711
Comments
I suggest either resolving this directly in the Sentry backend or adding a Proguard rule into the
In case such rule is added, I would suggest also updating the Sentry documentation for those projects that are not using the Gradle plugin. |
@ninniuz Thanks for raising this. Could you please share the org id in sentry.io with the repro? Agree regarding the docs but if |
The org id is |
I can see the mapping file is there and the exception type was not resolved so this looks like a bug indeed. |
Any update on this issue? It is very annoying and kills a lot of time on manually deobfuscation. |
Currently, since the proguard mapping file reuses the mangled name and only in combination with a line number is possible to resolve it, we are not able to resolve the class name. We haven't had the time to look for a solution yet. In other words, we will look at this again soon. Right now we have two engineers full time working on a better Android support. |
Ok here's the update: You need to define in your proguard rule to keep Exception names:
On the new SDK this will be included automatically |
Do you know if Crashlytics and others use this approach with line numbers in order to determine exception class name? Because I think at least on Crashlytics this problem was solved like years ago.
It doesn't look like a solution to the problem but mostly a workaround that will hit an obfuscation quality, which probably not acceptable to many users. |
This is a limitation of the proguard mapping file, and any crash reporting tool will hit it. This is what they have on their docs: https://docs.fabric.io/android/crashlytics/dex-and-proguard.html
The solution is simply to avoid mangling the exception names. |
If an app has no Proguard/R8 rule to keep Exception class names, then stacktraces on the website will miss the original class name.
Excerpt from the JSON event:
Note that the proguard mapping file has got a reference to this class hence Sentry's
symbolic
module could be able to de-obfuscate this reference:I have tested de-obfuscating this class reference using the
symbolic
python module and this is indeed true.It seems like Sentry backend service is not even trying to resolve
<module>.<type>
fromexception.values
items, but just stacktrace frames individually.I have got a very simple project setup on
sentry.io
to reproduce the issue, if needed.The text was updated successfully, but these errors were encountered: