Development/crashreporter

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

• Wiki Home
• Development
• Design
• QA
• Events
• Documentation
• Website
• Localization
• Accessibility
• Marketing
• Diversity
• Wiki Help

• Overview
• Reporting Bugs
• How to build
• Code Overview
• Git Commands
• Debugging
• EasyHacks
• Release Plan
• FAQ
• Developers
• Extensions
• → Open Issues

This is the documentation of our crash reporter service. The main focus is on the server side and the necessary maintenance tools.

The server side

Most of the following tools require either admin access in the admin interface or ssh access to the server.

Creating a new version

A new version can be created in the admin interface. The featured flag determines whether the version is shown in the chart. By editing an existing version it can also be made featured and therefore shown on the main page inside of the chart after the version object has been created.

Symbols for system libraries

The symbols for the system libraries need to be generated from time to time locally. For this the list with all missing symbols can be downloaded from the server. The file can be used as input into one of the helper tools for downloading microsoft symbol information. The generated zip file needs to be uploaded again with the upload script inside of the LibreOffice source code. Don't forget the --system command line flag for the upload script.

Bugzilla integration

The bugzilla integration is done by two scripts that are called from a cron job. The first script collects the information from the bugzilla instance about crash reports and updates the database. The second script updates the bug status and marks closed bugs as fixed in the database.

As both services interact with the server through the http part they are sensitive to misconfigured host entries in the nginx configuration.

Contributing to crashreport

These are some notes to help contributors to understand crashreport (https://crashreport.libreoffice.org/).

Overview

Crashreport is written with Django framework. Django uses the concept of applications that together creates a web app. In our case crashreport is divided in the following applications:

• api
• base
• crashsubmit
• management
• processor
• stats
• symbols

Each one is represented as a subfolder in the codebase (https://git.libreoffice.org/infra/crashreport/+/refs/heads/master/django/crashreport).

Every app can be composed of urls, views, models etc. each of those are one file inside a given folder.

Crashsubmit

When LibreOffice crashes the dump file is posted to crashsubmit application. Crashsubmit receives the dump and handles it.

Inside the application you will find different files, found in other Django applications. For this overview I will only highlight the following files.

crashsubmit
├── models.py
├── signals.py
├── urls.py
└── views.py

• models.py define a model in the sense used in ORMs, the fields in there are translated as a table in a DB, it defines keys, queries etc.
• signals.py contains kinds of triggers useful to schedule tasks for later, this will trigger post processing when a new dump is uploaded.
• urls.py defines the endpoints of the application
• views.py these are called when a URL is hit, it is similar to a controller in the ModelViewController pattern (which Django does not follow).

This is basically how it works, there is one endpoint that receives a dump file and version number of LibreOffice.

The urls calls a function in view, which validates the input data and stores the dump in the DB. This record in the DB is not complete, it does not include information about the dump, just hexadecimal codes.

How it is saved is defined in models.py.

And finally, signals.py defines what happens after a new dump is saved. Here signals will trigger a background job that parses the info in the dump and replaces the hexadecimal code with name of functions and other programming symbols.