Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Automated Error Reporting in Eclipse Mars

Automated Error Reporting in Eclipse Mars


Eclipse Mars comes with a built in error reporting tool that can be used to identify problems with Eclipse and automatically upload problems to a central server, providing key insights as to where problems may exist in Eclipse and how they can be improved. At present, errors identified in Eclipse are often shown with a dialog to the end user, or simply written to a log (visible with Window → Show View → Errors). Often these problems go ignored or unreported (or end up as complaints on social media). In addition, UI pauses can give a negative impression of the performance of Eclipse.

To try and improve the end user experience, the Error Reporting Tool can now automatically upload such error reports for committers to be able to identify and fix. This often solves the problem of users not having appropriate credentials for Eclipse's bug reporting site ( as well as inclination to do so. When the first error is logged, a dialog will be displayed asking the user whether they want to take part in improving the code base, in much the same way that mobile phones have an opt-in for sending reports to the server:

If enabled, Eclipse will send errors as they occur either all the time, once a day, or by asking permission from the user. InfoQ caught up with Marcel Bruch of Codetrails and Sergey Prigogin of Google to find out more about the projects, and started by Bruch asking where the idea of the error reporter came from:

Bruch:The idea of reporting errors is all around us for: Firefox, Apple, Microsoft, Google… they all ask their users to send problems they experience with the software back to the development teams. Eclipse was an exception here.
The development of the error reporter started because we felt a pain. After a new release we noticed a significant drop in network communication with our clients. Although we noticed that something was going wrong, we were not able to reproduce and thus find and fix the issue. 6 weeks and thousands of downloads later we received a bug report from a user telling us what was going wrong. This made us think about how we could empower our users to report issues faster and thus help us to produce more reliable software with shorter bug fix release cycles.

InfoQ: What kind of error reports does it upload?

Bruch:The reporter listens to all log events sent to the Eclipse logs, i.e., whatever shows up in the Eclipse Error Log view will be inspected and handled by the reporter. If the event is an error and was created by a plugin coming, we’ll show a small notification popup asking the user whether she wants to inform the project committers about that issue.

It’s worth mentioning that we do not respond to errors created by non-eclipse plugins (i.e., plugins whose symbolic name does not start with org.eclipse.*) nor do we listen to anything else than error events.

InfoQ: Are error reports anonymous?

Bruch:Yes, if you like. Except from a randomly generated ID,no personal data is collected. However, you may specify some contact data such as your email address, which allows us to contacts to you in case committers could not reproduce the issue or to let you know when a problem you reported has been fixed.

Even the error messages hidden in the stack trace can be anonymized if you want - although we do not recommend that because it contains valuable information in many cases.

InfoQ: Can the reporter be disabled if needed?

Bruch: Sure, but first I have to make clear that before any error report is sent,the reporter asks for your permission before sending the error
But you can also opt-out any time by simply disabling the reporter on its preference page.

InfoQ: Who has access to the bug reports?

Bruch:Only the reporter and the Eclipse committers have access to the report data.

InfoQ: Is it included by default in Eclipse?

Bruch: Yes. The work on the automated error reporter started 7 months ago and was part of the Eclipse Modeling and Eclipse Committers packager since Mars M2 (the second Mars Milestone build). With Mars M5 it became part of all Eclipse Mars Packages. During M5 we got excellent ideas how to further improve the reporter and the results of this feedback will be available in Mars M6.

InfoQ Has this been successful in finding or fixing errors so far?

Bruch: There are quite a few projects that make extensive use of this feature. Committers of the EGit, Xtext, Code Recommenders, Sirius, EMF Forms, Eclipse Store, JDT and Webtools projects are monitoring their incoming error reports and take necessary actions to fix them. In the meantime more than 80 errors have been fixed – which is quite a good result. But we hope to further increase that number to make Mars a great release.

InfoQ: Why is it important for users to send error reports?

Bruch: The short answer is: Because developers can’t fix what they don’t know is broken.

Every developer knows that developing a system that runs on millions of desktops with millions of different and very individual configurations is challenging and cannot be covered completely by unit tests. Thus, and to get your problems fixed, we need you to report them to committers as early as possible. Thanks in advance!

In addition to the normal error reporting, there is also a dedicated UI pause detection tool, which identifies when the user event processing loop is being blocked by a lengthy calculation. This often indicates code that should not be running on the UI loop, such as a slow network performance or heavy lifting that does not need to be there. Google developed a tool, subsequently introduced into Eclipse Mars, to detect these errors – and with the help of the Eclipse Error reporter has helped identify problems already. InfoQ asked Sergey Prigogin how the project started:

Prigogin: It was created five years ago to help identify UI pauses that we experienced and needed to prioritize our work on them. We did it by categorizing them and tallying cumulative time lost by Google engineers to each type of UI freeze.

InfoQ: What was necessary to move it from supporting Eclipse 3.x to the new Eclipse 4 model?

Prigogin: The hook for it in Eclipse 3.x was in the code that disappeared in 4.x. The current approach based on SWT events would work in 3.x, but at the time we used a less robust approach.

InfoQ: How does it work?

Prigogin: There is a dedicated monitoring thread that receives notifications from the UI thread when processing of an event starts and ends. The thread captures stack traces of the UI and, optionally, other threads and writes warning and error messages to the Eclipse error log when event processing takes longer than a configurable threshold.

InfoQ: Which Eclipse packages is it enabled for, and is it possible for users to enable/disable the collection of UI events?

Prigogin: It is enabled by default in "Eclipse IDE for Eclipse Committers". It is also part of Eclipse Platform feature, which means that it is included in all Eclipse packages, where it can be enabled through the preferences page.

InfoQ: Has there been any successes of errors that have been fixed that were caught with this tool?

Prigogin: Lars Vogel mentioned that the EGit project has been very responsive to fixing bugs detected by the tool, including Matthias Sohn fixing a several second pause in Bug 452388.

The UI pause detection tool and the error reporting tool are in use by Eclipse committers through the Eclipse IDE for Committers package, and this should help ensure that Eclipse Mars is the most performant version of Eclipse yet.

Rate this Article