Difference between revisions of "CrashReporting"

Revision as of 15:14, 26 August 2008

CrashReporting is an important feature that helps to solve any stability problems in StarOffice or OpenOffice.org.

What is Crash Reporting?

Should the application ever crash, details about the crash are reported to a central server, where they are collected and classified. Developers get notified about these crashes, so they can look into them in detail to find the root cause and solve it.

Questions and Answers

My Office crashed! What to do?

In the unlikely case that Office crashed you shouldn't worry too much:

• next time you start Office it usually succeeds in recovering your documents
• the CrashReporting dialog will guide you through sending details about the problem

Please allow the crash details to be sent. It helps to improve the application quality, which will benefit users like yourself.

The CrashReporting dialog asks about details. What should I write?

Imagine telling another user: "I just did X and Y, then it crashed! Can you believe this? Here, try it yourself. See? That's exactly what I meant!"

Now just write up what "X and Y" are.

OpenOffice.org's issuezilla already knows about this problem!

Knowing that a crash is already handled in issuezilla is a very important detail. Please help others to see this relationship too:

When you restart Office after it crashed the CrashReporting dialog will guide you to provide all the details

• mention the issue number in the subject line
• provide your email address, so the server can acknowledge your report
• the automated reply will contain a ReportID, which developers need to know to debug the exact problem you experienced. Please mention the ReportID in the issue.

Can't I just copy and paste the crash details into the issue?

No, please don't. There are two important reasons:

• The crash you saw will not show up in any statistics about the product quality. These statistics are an important guide on where to spend valuable resources.

• For a detailed analysis of the crash you just suffered developers need a lot of details about the program. The Office build you are running only contains the most essential debugging details. Having all details would bloat the installation enormously without providing any benefit for you.

My version of the Office application doesn't seem to have this CrashReporting feature?

The raw data submitted via the CrashReporting feature does not nearly have enough details to allow proper debugging or even classification of a problem. The report only becomes usable to development if the exact binaries of your application are known to the server. Sun's server only knows binaries built by Sun itself.

So only StarOffice and OpenOffice.org versions provided by Sun have this feature enabled.

I'm worried about my privacy: Will my crash report be published?

No, details of your report are treated confidentially.

How does the Tool work internally?

The crash reports are stored in a database and compared with other reports. Developers can then look at that and try to fix the problems causing the crashes.

The application will than send a SOAP request to a server collectiong those reports. The report contains an XML document along with binary data and a description text. The server can be configured in the bootstrap.ini file and the default for OpenOffice.org is http://report.services.openoffice.org, that´s where Sun is collecting OpenOffice.org crash reports.

There is no public access to data collected by the server operated by Sun due to privacy concerns. The code used on the server side has not been open sourced.

The Receiving SOAP Service at http://report.services.openoffice.org is just a small SOAP service with the signature

 public static String submitReport(SOAPContext soapContext,String body, Hashtable attachments )

which collects the report which will than be rsynced into the internal network and be given to a next instance service which then stores the report into a database. Then there is a third service using 2 processes on different hosts involved which tries to find similarities between stacks stored in the database based on the information originally send in the reportmail.xml document, this then groups similar stacks together and assigns one StackMatchID into the database. Here there is some kind of well almost "fuzzy logic" involved in detecting similarity and there can be false positives while doing that and on the other hand also sometimes the same problem root cause might lead to serveral StackMatchIds. Sun developers have an internal (also closed source) web frontend to access the crash report database and some commandline tools are also available to Sun developers. Sun also does some statistical analysis of the data collected in order to find highscorers that need more urgent fixing for example. Sun handles crash reports by comparing them with other reports received and generating and priorizing tasks for Sun developers into an internal bug tracking system automatically based on volume and frequency of occurance of similar reports. This complexity in the backend services is only needed because of the large amount of data generated by the Sun provided OpenOffice.org builds and StarOffice. For other OpenOffice.org builds or OpenOffice.org based products which may not have such a high number of users much simpler szenarios of handling reports could be possible.

Information about the UI for sending crash reports in OpenOffice.org/StarOffice can be found in the Error Report UI Spec for OO.o 2.0 document.

There is also a Crash Report XML Document format specification document available which describes the XML format of the reportmail.xml document send with the SOAP request.

There is a crash report related Environment Variable STAROFFICE_USERTYPE which will be recognized when the crash is being reported. Valid values are "qa", "developer" and "internal". It´s value will be included in the crash reports XML document if set and marks the report as belonging to a certain usertype group. The only use for that setting is that the crash report database can be asked afterwards how many reports there where of those groups as opposed to normal users.

Note to those providing non-Sun OpenOffice.org builds: You can either disable CrashReporting for your build or you can provide your own backend services for handling crash reports. Using the Sun backend for non Sun Builds does not make sense because to be able to work with the data provided in the report access to the complete solver output tree of the corresponding build must be available in order to obtain debug information for that version. And the Sun backend obviously does not have access to the solver tree of your build. The configure tool in config_office has a commandline switch to enable/disable crash reporting. AFAIK currently only Sun operates an backend infrastructure to handle crash reports. If you have different information please modify this Wiki entry. Occassionally the Sun backend receives reports from OpenOffice.org builds not provided by Sun or from OpenOffice.org based products not provided by Sun, this is an error if you happen to be the provider of such a build please correct it.

What Red Hat does

For Red Hat builds Red Hat replaces the crash_report program with a simple gui script which collects some extra commonly relevant information about the environment in which OpenOffice.org has been run as well as the stack trace and prompts the user to submit it to Red Hat's bugzilla. And we use a similar set of tools to map the stripped stack back to the debuginfo for that version of OpenOffice.org

A better longer term solution would be for Red Hat to point bugbuddy into their own bugzilla backend and then hook openoffice.org up to it and work on some common backend for all our of apps to find dups and present the developer with a pre-restored set of line numbers and details.