Difference between revisions of "CrashReporting"
m |
m |
||
Line 54: | Line 54: | ||
could be possible. | could be possible. | ||
− | Information about the UI for | + | Information about the UI for sending crash reports in OpenOffice.org/StarOffice can |
be found in the [http://specs.openoffice.org/appwide/errorreporter/error_report_2_0_ui_specification.sxw Error Report UI Spec for OO.o 2.0 ] document. | be found in the [http://specs.openoffice.org/appwide/errorreporter/error_report_2_0_ui_specification.sxw Error Report UI Spec for OO.o 2.0 ] document. | ||
Revision as of 16:36, 15 November 2006
CrashReporting is a feature of some OpenOffice.org and StarOffice distributions. When the application crashes data about the crash is collected and send to a server to be stored in a database and compared with other reports. Developers can than look at that and try to fix the problems causing the crashes.
Crash Reporting is by default enabled in Sun provided OpenOffice.org builds and in StarOffice. Crash Reports of these builds are send to a Sun server handling these reports.
After OpenOffice.org/StarOffice crashed on the next restart of the application the User will be presented a dialog where information about the crash can be entered and the crash report can be send.
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 than
stores the report into a database. Than 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 than groups similar
stacks together and assigns one StackMatchID in 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 in 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.