# How can I track a bug that caused a crash and was reported via apport / whoopsie?

It used to be that when a program crashed, especially when a user was using a pre-release of Ubuntu, apport could be used to open a bug report. The user could then track the bug, see if it affected others, help fix it, etc.

As of Precise 12.04, this behavior and workflow changed. As I discovered in Bug #993450 “Apport fails to submit bug report”, by default apport no longer opens a bug report (and it is awkward but not impossible to get it to do so). At the same time people are noticing a new "whoopsie" process, as described at What is the 'whoopsie' process and what does it do?.

After some more googling, I dug this blueprint up, which describes the whole process: ErrorTracker - Ubuntu Wiki. (It didn't mention whoopsie or daisy, so I added them - please correct me if I got it wrong).

Wow - this sounds like great work to streamline and improve the crash reporting process.

I'm left with this question: how does a user learn what the status of the problem is? The blueprint now has this requirement

The user should have some way to check back on the status of their crash report; e.g. have some report ID they can look at to see statistics and/or any associated bug #. E.g. provide a serial number at time of filing that they can load via a web page later on.

which seems unimplemented. Is there anything available in the meantime?

And how does a developer get into the game? Going to https://daisy.ubuntu.com just provides an "Incorrect Content-Type" error message.

Finally, I suggest documenting the apport behavior changes in the Release Notes. It should be of interest to anyone who has been trying to help out Ubuntu.

-
Related: askubuntu.com/questions/159957/… –  student Jul 23 '12 at 7:32

Thanks for your interest in the Ubuntu error tracker project.

As of Precise 12.04, this behavior and workflow changed. As I discovered in Bug #993450 “Apport fails to submit bug report”, by default apport no longer opens a bug report (and it is awkward but not impossible to get it to do so).

Apport never created bug reports post-release. When a release is still in development you can use apport to file Launchpad bugs (and error reports).

In a final released version of Ubuntu we now show error dialogs. This is a great improvement from a program "going away" without any feedback and the user being left wondering what just happened.

The statistics from the data collected when people choose to send these reports show up on http://errors.ubuntu.com.

I'm left with this question: how does a user learn what the status of the problem is? The blueprint now has this requirement

The user should have some way to check back on the status of their crash report; e.g. have some report ID they can look at to see statistics and/or any associated bug #. E.g. provide a serial number at time of filing that they can load via a web page later on.

I'm going to remove that. That was never the intent. The user interface is careful not to make promises about getting any feedback on the report.

These are not bug reports.

Our intent is to reduce the amount of time it takes for developers to find the most pressing issues, collect the needed information to fix them, and get the fixes to users.

We've solved the problem of finding the most pressing issues. That's the front page of http://errors.ubuntu.com.

Collecting the needed information quickly, and without involving a long feedback loop with users who are experiencing the problem is addressed in foundations-q-bucketing-improvements. The plan is to allow developers to hook into the information collection process server-side. If I need /var/log/syslog but it's not already provided, I just change a setting on http://errors.ubuntu.com and the next person who experiences the error automatically adds it to the data they're sending.

Getting fixes to users quickly is addressed in foundations-q-updates-from-crash-reports. When users submit an error report and that error has already been fixed and released, a dialog will come up asking if they would like to upgrade to the version of the software which fixes the problem they just experienced.

And how does a developer get into the game? Going to https://daisy.ubuntu.com just provides an "Incorrect Content-Type" error message.

http://daisy.ubuntu.com is not intended to be used by humans. It's there for the error reporting daemon (whoopsie) to send reports to.

It would be absolutely wonderful for other people to get involved. I'm currently the only one hacking on this full-time.

There are four parts to the system.

• Apport, which provides the desktop user interface.
• Whoopsie, which takes reports (and core dumps) created by Apport and shovels them into the error tracker server, Daisy.
• Daisy, which collects reports from Whoopsie and processes them. This is the heart of the service. It's what turns the core files into retraced reports and generates the statistics you see on http://errors.ubuntu.com.
• Errors, which is a Django-based website providing both a human readable view of the data and a RESTful API for working with it.

There is a slightly out-of-date set of scripts under the setup/ directory in lp:daisy that should give you some idea of how the pieces fit together. I've been working on juju charms to replace this. The goal is a single command to deploy the entire infrastructure in the cloud for testing and development.

You can find my email address on Launchpad if you have further development questions.

-
"The statistics from the data collected when people choose to send these reports show up on errors.ubuntu.com."; This is not correct, only if your app is written in a supported programming language. For example no program written in mono has errors reported there. This is discriminatory in the extreme. Ubuntu should provide an even playing field and not exclude programs based on the language they are written in. –  trampster Jun 12 '12 at 10:14
I think you missed the part where he's working on this alone, mate. There's no issue with supporting popular languages first. –  Vadi Jun 12 '12 at 23:41
Indeed, @Vadi is correct. There is nothing discriminatory about this. If someone wants to step up and implement Mono support, I'll happily review and merge their apport branch. –  Evan Jun 13 '12 at 11:00

To view the accumulated submitted crash reports you can go to https://errors.ubuntu.com/

-
Thanks. But it still isn't clear how I can track the status of problems I've run into, and the site is a bit hard to figure out (How to interpret errors.ubuntu.com graph data? - Ask Ubuntu) –  nealmcb Jun 5 '12 at 19:50

You have to enable apport in /etc/default/apport file.

sudo nano /etc/default/apport


Then change the value of enabled from 0 to 1.

-
As I noted in the bug report referenced in the question, as of Precise, apport no longer submits bugs unless you change the python script, so the question is how to track progress without a bug. –  nealmcb Jun 5 '12 at 19:42
Well, I am submitting errors time to time, they are going to launchpad, from launchpad you will get even emails about the changes made on your error report. For example check here this error report submitted by me. –  Frantique Jun 6 '12 at 6:43
That is a "ProblemType: Bug" report, which I assume you manually initiated from the apport-bug command or the like. The behavior which changed for Precise is that crashes which apport notices are not reported as bugs, but rather sent into the new ErrorTracker. I'm trying to find out how to continue to track these crash bugs. –  nealmcb Jun 6 '12 at 13:22
Fill it with: apport-bug packagename –  Frantique Jun 6 '12 at 14:03
Sigh - reporting it via apport-bug would the bug report wouldn't have all the details that apport has already discovered as part of its crash reporting capability, and already reported to the errors.ubuntu.com site! –  nealmcb Jun 6 '12 at 20:17