Quick update about crash reporting and some open issues

Markus Mohrhard markus.mohrhard at googlemail.com
Mon Jun 27 04:00:25 UTC 2016


so here is a quick update about the crash reporting and a few questions
about open issues. It would be good if people who are going to use the
service to have a quick look through the items and tell me their opinion
about the open items.

So starting with the update:

I just fixed the signature generation and started the work on the 64bit
Windows system library support. All reports have been reprocessed and the
signature no longer contains an offset. This finally merges x64 and x86
reports under the the same signature.
The summary view in the signature page has a basic implementation and just
needs some extending to other things that are useful. A few that are on my
list are OpenGL device, OpenGL vendor, better windows version summaries and
generic metadata support.

What still needs to be implemented and is quite high on the issue list is
to add a reference from the crash details page back to bugzilla.

Then a few open questions about process around the crash reporting:

Do we want some way for the ESC to get a list of the 10 most frequent
crashes of the last week or something like that?

Do we want to notify the crash reporter if there was a commit referencing a
crash report? Similar to how bugzilla is automatically updated we could do
something like this for the crash reporter. That might help with keeping
track if there was already a fix for a crash and we are only seeing more
reports because it is not yet in a released version.
What would be the format of the reference?

How do we want to handle stuff that requires user interaction? Examples are
adding new versions, adding references to bug reports and possibly export
of crash reports to bugzilla.
For the bugzilla to crash report direction we had planned to handle it with
a bot monitoring the crash report field in bugzilla and update the crash
reporter website.
There are maybe more tasks in the future that will require some actions
that cause DB changes by users. Duplicating the login system from bugzilla
seems like a horrible concept and will just cause us to have even more
logins that nobody remembers.

How do we want to handle old crash reports? We can't keep the reports
forever and will most likely delete them as soon as a branch becomes EOL.
The question is whether there is value in exporting them to some format
(most likely json) and archive them or just forget completely about old

There is an exploitability feature in breakpad that can do an automatic
assessment but I have no idea how good the reports are. I know that it is
enabled but only visible in the Mozilla version. Do we want something like
that and if we want it do we want to hide it?

I'll have most likely a few more items that will come up after the release.
I hope that the current service is already useful. If there is anything
else missing please let me know.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20160627/e4447403/attachment.html>

More information about the LibreOffice mailing list