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

Online crash reporting #1853

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

Online crash reporting #1853

lazka opened this issue Feb 23, 2016 · 10 comments

Comments

@lazka
Copy link
Member

@lazka 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
Copy link
Member Author

@lazka lazka commented Sep 18, 2016

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

@declension
Copy link
Member

@declension 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
Copy link
Member Author

@lazka 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
Copy link

@NoahAndrews 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
Copy link
Member Author

@lazka 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
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
Copy link
Member Author

@lazka 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
Copy link
Member Author

@lazka 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
Copy link
Contributor

@urielz 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
Copy link
Member Author

@lazka 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
Copy link
Member Author

@lazka 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
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
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
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
Online crash reporting. See #1853
@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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants