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

Online crash reporting #1853

Closed
lazka opened this Issue Feb 23, 2016 · 10 comments

Comments

Projects
None yet
4 participants
@lazka
Member

lazka commented Feb 23, 2016

It would be nice to add a way to allow the user to submit a crash report to us in some way.

For Python exceptions we should display a short stacktrace and remove paths/usernames. In case the user has faulthandler installed we could write the C stacktrace to a file and suggest to report it on the next QL start.

Remaining questions:

  1. Where to submit to?
  2. How to prevent DOS? Captcha?

@lazka lazka added the enhancement label Feb 23, 2016

@lazka lazka referenced this issue Mar 14, 2016

Closed

TLS support #1895

0 of 4 tasks complete
@lazka

This comment has been minimized.

Member

lazka commented Sep 18, 2016

We could use sentry: https://sentry.io/welcome/

@declension

This comment has been minimized.

Member

declension commented Sep 18, 2016

Yes, Sentry would be cool actually. Didn't think of it (and didn't realise it had a fairly generous free tier) :)

@lazka

This comment has been minimized.

Member

lazka commented Jan 11, 2017

They have recently revised their pricing, but the basic one is still free. I feel confident that they wont remove the free option or disappear and that we can depend on it to some extend. In the end most of the work required would also be useful for other services.

My current thinking:

  • It would be nice to have this at the switch to Python 3. I assume that there will be quite a bit of fallout and catching that early would be nice.
  • We can depend on faulthandler, write Python stack traces to disk on segfault and on the next start raise the error, pushing it to the crash reporter.
  • Since python-raven (sentry client) isn't in debian we can make the crash reporting pluggable and put the python package at the right place for our Windows/macOS/PPA builds and not include it in the tarball.

One question remaining is how to present errors to the user. Just showing "submit error" will give us more tracebacks but makes it harder to reproduces some errors because we have no channel to ask questions. Providing both options with a short explanation might do the trick ([2] "Report error to us on github" [1] "Just send error log (better than nothing)")

@NoahAndrews

This comment has been minimized.

NoahAndrews commented Jan 11, 2017

Perhaps we should also have an in-app text box so they can at least say what they were doing when the app crashed.

@lazka lazka added this to the 3.9.0 Release milestone Feb 25, 2017

@lazka

This comment has been minimized.

Member

lazka commented Feb 25, 2017

@NoahAndrews good idea. sentry has a user feedback interface, but that is javascript only. Maybe we can reuse the API locally.

lazka added a commit that referenced this issue Feb 27, 2017

Better integration of faulthandler. See #1853
Instead of writing the stacktrace to stderr, write it to
~/.quodlibet/faultdump and on the next start raise an
exception with the content.

Slightly adjust the exception dialog to use a text view for the
exception message instead of a tree view header since the passed
text from the faulthandler stack trace can be quite long.
@lazka

This comment has been minimized.

Member

lazka commented Mar 7, 2017

I've wrapped the whole thing to get the following API now:

sentry = Sentry(SENTRY_DSN)

def foo3():
    a = 6
    try:
        object.fooo5
    except Exception:
        try:
            err = sentry.capture()
            err.set_feedback("my python3 commentöäp")
            err.send(SENTRY_TIMEOUT)
        except SentryError:
            print("something broke, sorry")

Regarding how to ship python-raven: it just entered debian last week, so nothing in ubuntu for some time. An easy solution might be to just vendor the whole library and depend on its only dependency: contextlib2. If we then don't include it in the MANIFEST.in it wont get included in the tarball but we will use it in all windows/osx/PPA builds because they use the git checkout directly.

@lazka

This comment has been minimized.

Member

lazka commented Mar 7, 2017

For the UI I have the following in mind:

---------------------

Oops, an error occurred. You can ignore this error, but Quod Libet might be
unstable from here on out.

Error details (expander):

....Stack trace
....Stack trace
....


[Submit Error Report]/[Open a Bug Report] [Quit Program] [Ignore Error] <- Default

--------------


[Open a Bug Report] -> Opens github with a prefilled bug report

[Submit Error Report] -> Opens:

------------------

Various details regarding the error will be send to a third party online
service (sentry.io)

Report Details (expander):

.... The raw data we will send
.... The raw data we will send
....

(optional) Please give a short description of what you did when the error
occurred: [                                 ]


[Cancel] [Submit Report] --> makes window insensitive and adds a spinner.

If an error occurs shows an error message and makes window sensitive again. If
it succeeded: close the submit window. The user can then decide to ignore the
error or quit QL.

------------------

@urielz

This comment has been minimized.

Contributor

urielz commented Mar 7, 2017

UI looks good to me. One question, from what you wrote I take that this doesn't handle CTDs? If so, can something similar be implemented for those cases? For example by asking the user to submit the bug report the next time QL is launched...

@lazka

This comment has been minimized.

Member

lazka commented Mar 8, 2017

Thanks. Crash to desktop? If yes, we currently raise a Python exception containing a stacktrace on the next start: https://twitter.com/QuodLibetApp/status/836534027096109056 .

@lazka

This comment has been minimized.

Member

lazka commented Mar 8, 2017

screenshot from 2017-03-08 17-18-28

screenshot from 2017-03-08 17-14-53

lazka added a commit to lazka/quodlibet that referenced this issue Mar 11, 2017

Online crash reporting. See quodlibet#1853
Most of the error reporting is now in quodlibet.errorreport

* Logging the error and printing to stdout
* Writing the error + recent logs to disk
* Showing the error to the user
* Opening a pre-filled github issue
* Sending the error sentry.io (github fallback)
* Logging/reporting segfault stacktraces

Depends on raven, which is unlikely to be installed atm, maybe we'll vendor it.

lazka added a commit to lazka/quodlibet that referenced this issue Mar 14, 2017

Online crash reporting. See quodlibet#1853
Most of the error reporting is now in quodlibet.errorreport

* Logging the error and printing to stdout
* Writing the error + recent logs to disk
* Showing the error to the user
* Opening a pre-filled github issue
* Sending the error sentry.io (github fallback)
* Logging/reporting segfault stacktraces

Depends on raven, which is unlikely to be installed atm, maybe we'll vendor it.

lazka added a commit to lazka/quodlibet that referenced this issue Mar 14, 2017

Online crash reporting. See quodlibet#1853
Most of the error reporting is now in quodlibet.errorreport

* Logging the error and printing to stdout
* Writing the error + recent logs to disk
* Showing the error to the user
* Opening a pre-filled github issue
* Sending the error sentry.io (github fallback)
* Logging/reporting segfault stacktraces

Depends on raven, which is unlikely to be installed atm, maybe we'll vendor it.

lazka added a commit that referenced this issue Mar 15, 2017

@lazka lazka closed this Mar 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment