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

Top-level exception handling #681

Closed
3 tasks done
krestenlaust opened this issue Jun 15, 2023 · 6 comments
Closed
3 tasks done

Top-level exception handling #681

krestenlaust opened this issue Jun 15, 2023 · 6 comments
Labels
3 - medium priority This issue needs to be considered, but may not be a priority for the next release enhancement New feature or request

Comments

@krestenlaust
Copy link

  • Did you check to see if this issue already exists?
  • Is this only a single feature request? Do not put multiple feature requests in one issue.
  • Is this a question or discussion? Don't use this, use https://lemmy.ml/c/jerboa

"We should probably implement some sort of top level exception handling that allows the user to submit a bug report directly from the app to make it easier to get a full backtrace. If you can get the full backtrace from logcat that'd be great." - #538 (comment)

@krestenlaust krestenlaust added the enhancement New feature or request label Jun 15, 2023
@twizmwazin twizmwazin added the 3 - medium priority This issue needs to be considered, but may not be a priority for the next release label Jun 15, 2023
@MV-GH
Copy link
Collaborator

MV-GH commented Jun 15, 2023

How will the stacktraces look from a release build?

i ve seen some before and they are basically useless

example

	at r.u0.<init>(Unknown Source:72)
	at f1.c.y0(Unknown Source:28)
	at d5.j.X(Unknown Source:173)
	at n0.b.a(Unknown Source:50)
	at n0.b.X(Unknown Source:8)
	at s.j0.T(Unknown Source:181)
	at n0.b.b(Unknown Source:50)
	at n0.b.T(Unknown Source:8)
	at o.t.a(Unknown Source:2503)
	at o.t.Y(Unknown Source:317)
	at n0.b.Y(Unknown Source:58)
	at f7.i.t(Unknown Source:182)
	at x.c1.k(Unknown Source:182)
	at s.t.T(Unknown Source:152)
	at n0.b.b(Unknown Source:50)
	at n0.b.T(Unknown Source:8)
	at t.c.g(Unknown Source:80)
	at s.v.g(Unknown Source:61)
	at t.a.g(Unknown Source:67)
	at s.w.g(Unknown Source:12)
	at n.l0.a(Unknown Source:169)
	at n.l0.Y(Unknown Source:161)
	at n0.b.Y(Unknown Source:58)
	at f7.i.t(Unknown Source:182)
	at p0.h.f(Unknown Source:113)
	at t.k0.f(Unknown Source:32)

We could probably disable obfusication if isnt already since it's foss anyway but minimization/release optimizations will still make it look like that

@beatgammit
Copy link
Contributor

beatgammit commented Jun 16, 2023

It looks like GlitchTip is FOSS and supports android reporting, but I have no experience with it. I also don't know how this interacts with optimizers. We could, at the very least, manage exception messages better.

I have seen that raygun supposedly works with R8/ProGuard, but that's not free and probably not worth paying for with the current scale of Jerboa.

Anyone have any experience with other tools? I use Sentry at work, so I'm partial to GlitchTip.

@MV-GH
Copy link
Collaborator

MV-GH commented Jun 16, 2023

@FilippoVigani
Copy link

I've always used Sentry at work. I know Firebase Crashlytics also de-minifies/de-obfuscates if you provide source maps, and it's free afaik. I'm not sure how to open it for OSS projects though.

@MV-GH
Copy link
Collaborator

MV-GH commented Jul 5, 2023

I have disabled obfuscation, and the stack traces are pretty readable. Dessalines won't agree to it unless its FOSS and we can host it ourselves.

@dessalines
Copy link
Member

Fixed by above PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3 - medium priority This issue needs to be considered, but may not be a priority for the next release enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants