Unnecessary noise reported in stack traces in Sentry 2.0.0

[mrmitew]

Platform:

• Android ->
  build tools: 29.0.2
  compileSdk: 28
• Kotlin -> Unrelated to the issue

IDE:

• Android Studio -> Unrelated to the issue

Build system:

• Gradle -> Unrelated to the issue

Android Gradle Plugin:

• Yes -> Unrelated to the issue

Sentry Android Gradle Plugin:

• No

Proguard/R8:

• Enabled

sentry-android installed with:

• JCenter

The version of sentry-android:
2.0.0

---

I have the following issue:

Since upgrading Sentry's SDK version to 2.0.0, stack traces for all events contain 10 unnecessary, just "noise-making" traces.

Steps to reproduce:

• Step 1 Report exception

Actual result:

 at dalvik.system.VMStack.getThreadStackTrace(VMStack.java)
    at java.lang.Thread.getStackTrace(Thread.java:1567)
    at java.lang.Thread.getAllStackTraces(Thread.java:1617)
    at io.sentry.core.SentryThreadFactory.getCurrentThreads(SourceFile:38)
    at io.sentry.core.MainEventProcessor.processNonCachedEvent(SourceFile:75)
    at io.sentry.core.MainEventProcessor.process(SourceFile:49)
    at io.sentry.core.SentryClient.io.sentry.core.ISentryClient.captureEvent(SourceFile:91)
    at io.sentry.core.SentryClient.io.sentry.core.ISentryClient.captureException(SourceFile:1119)
    at io.sentry.core.Hub.io.sentry.core.IHub.captureException(SourceFile:144)
    at io.sentry.core.Hub.io.sentry.core.IHub.captureException(SourceFile:1073)
    at io.sentry.core.Sentry.captureException(SourceFile:205)
/* --> From this point on, is what we care about */

Expected result:

• To not see the internals of Sentry unless crash happened because Sentry itself

[marandaneto]

hey @mrmitew thanks for your message.

By default, only the package of your App. will be shown on the UI, See:

You can also customize that setting:
SentryOptions.inAppExcludes and SentryOptions.inAppIncludes

See https://docs.sentry.io/platforms/android/ In Application Stack Frames section.

Does that help you? thanks.

[mrmitew]

Thank you for your answer @marandaneto But I don't see 'App only' option.
Sentry is not on premise, but hosted on sentry.io

If I use the inAppExcludes and Sentry crashes due to a bug, would still the stack trace be reported? Are there any consequences of using it or those will be just hidden in one of the tabs (that I don't see at the moment)

[marandaneto]

it just hides on the UI, stack traces are still sent.

This button won't be shown if all frames are inApp or not-inApp, which might be the cause to not be shown.

by default, we do addInAppInclude(packageName) which is your applicationId build.gradle, but we can only get the packageName on runtime, not all of your packages if using Android lib modules.

Try adding all of your root packages that differ from your packageName.

eg your applicationId is io.company.myapp.android
and you have a lib called io.company.sharedlib.android

I'd recommend calling addInAppInclude for io.company.sharedlib as well, let me know if that works :)

[mrmitew]

by default, we do addInAppInclude(packageName) which is your applicationId build.gradle, but we can only get the packageName on runtime, not all of your packages if using Android lib modules.

But io.sentry* does not match the package name of the app by any means. Shouldn't be excluded by default then?

But in any case.. why is this considered as important to report:

at dalvik.system.VMStack.getThreadStackTrace(VMStack.java)
    at java.lang.Thread.getStackTrace(Thread.java:1567)
    at java.lang.Thread.getAllStackTraces(Thread.java:1617)
    at io.sentry.core.SentryThreadFactory.getCurrentThreads(SourceFile:38)
    at io.sentry.core.MainEventProcessor.processNonCachedEvent(SourceFile:75)
    at io.sentry.core.MainEventProcessor.process(SourceFile:49)
    at io.sentry.core.SentryClient.io.sentry.core.ISentryClient.captureEvent(SourceFile:91)
    at io.sentry.core.SentryClient.io.sentry.core.ISentryClient.captureException(SourceFile:1119)
    at io.sentry.core.Hub.io.sentry.core.IHub.captureException(SourceFile:144)
    at io.sentry.core.Hub.io.sentry.core.IHub.captureException(SourceFile:1073)
    at io.sentry.core.Sentry.captureException(SourceFile:205)

That's unnecessary bytes sent over the internet. Is it going to be differ per event? Does not bring any value for the developer, unless its a crash caused by Sentry itself.

Personally I like reading the raw stack trace and this just adds way too much noise in my opinion :(

[marandaneto]

you probably captured an exception which is also not inApp either and all the frames are considered not-inApp.
would you mind sharing the link of your org and project (maranda@sentry.io)? I can double-check it.

[marandaneto]

by default, we do addInAppInclude(packageName) which is your applicationId build.gradle, but we can only get the packageName on runtime, not all of your packages if using Android lib modules.

But io.sentry* does not match the package name of the app by any means. Shouldn't be excluded by default then?

But in any case.. why is this considered as important to report:

at dalvik.system.VMStack.getThreadStackTrace(VMStack.java)
    at java.lang.Thread.getStackTrace(Thread.java:1567)
    at java.lang.Thread.getAllStackTraces(Thread.java:1617)
    at io.sentry.core.SentryThreadFactory.getCurrentThreads(SourceFile:38)
    at io.sentry.core.MainEventProcessor.processNonCachedEvent(SourceFile:75)
    at io.sentry.core.MainEventProcessor.process(SourceFile:49)
    at io.sentry.core.SentryClient.io.sentry.core.ISentryClient.captureEvent(SourceFile:91)
    at io.sentry.core.SentryClient.io.sentry.core.ISentryClient.captureException(SourceFile:1119)
    at io.sentry.core.Hub.io.sentry.core.IHub.captureException(SourceFile:144)
    at io.sentry.core.Hub.io.sentry.core.IHub.captureException(SourceFile:1073)
    at io.sentry.core.Sentry.captureException(SourceFile:205)

That's unnecessary bytes sent over the internet. Is it going to be differ per event? Does not bring any value for the developer, unless its a crash caused by Sentry itself.

Personally I like reading the raw stack trace and this just adds way too much noise in my opinion :(

it's a way of tracking down our own issues, as we can't really have our own, you can filter them using the BeforeSendCallback callback.

[marandaneto]

@mrmitew did the answers above helped you?

[mrmitew]

you probably captured an exception which is also not inApp either and all the frames are considered not-inApp.

It should be in-app, because it has the same package name as the app. So there should be another reason I guess.

it's a way of tracking down our own issues, as we can't really have our own, you can filter them using the BeforeSendCallback callback.

But if it is an exception, thrown by the app, and not by Sentry, why are they still sent? Can't the thread stacktrace be separated from the stack trace of the thrown exception? It only adds noise to the non sentry developers.

[marandaneto]

you probably captured an exception which is also not inApp either and all the frames are considered not-inApp.

so please share the org and project or a raw event json, if this is the case, we have a bug, but so far I could not reproduce it, also a sample repro would help, thanks.

It should be in-app, because it has the same package name as the app. So there should be another reason I guess.

it's a way of tracking down our own issues, as we can't really have our own, you can filter them using the BeforeSendCallback callback.

But if it is an exception, thrown by the app, and not by Sentry, why are they still sent? Can't the thread stacktrace be separated from the stack trace of the thrown exception? It only adds noise to the non sentry developers.

I kinda agree and would understand it as an improvement, but this has not changed, the old version also sends all the frames afaik.

[marandaneto]

after digging into it, this feature is opt-in by default on 2.0.1, fixed by #267 a while ago.
you only get the full stack trace of all the threads if attachStacktrace and attachThreads are enabled otherwise you get the stack trace of the exception only.

Please upgrade the SDK to min. 2.0.1 and let us know if you find any issues, thanks.