Apport fails to submit bug report

[Moritz Naumann]

I just had evince crash twice in a row (and can reproduce this crash), and each time apport started up as expected and i was notified about an application crash and given the option to report it. I chose to report it both times, and that was the last thing I got to see about this crash report. The report window closed and the next thing I expected to see would be a new tab in the already running Firefox browser, where the bug report would have been created with the retrace info appended - but this did not happen.

To create /this/ bug report (manually triggered via "ubuntu-bug apport") this very mechanism worked as expected - the new Firefox tab opened (without restarting Firefox) and I am now submitting this bug report.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: apport 2.0.1-0ubuntu7
ProcVersionSignature: Ubuntu 3.2.0-24.37-generic 3.2.14
Uname: Linux 3.2.0-24-generic x86_64
ApportVersion: 2.0.1-0ubuntu7
Architecture: amd64
Date: Wed May 2 20:11:32 2012
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 PATH=(custom, user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: apport
UpgradeStatus: Upgraded to precise on 2012-04-27 (5 days ago)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[emptythevoid (emptythevoid)]

I had a dup of this bug. I have the same issue after upgrading from 10.04 to 12.04. Apport shows that it's collecting data, but does not bring up Firefox at all (either from cold, or in a tab) to submit the bug. If apport is called using ubuntu-bugs or ubuntu-bugs -w, it works as expected - it's only when it shows up after a program has crashed, and asks if you want to submit a report.

[emptythevoid (emptythevoid)]

Moritz, how are you crashing evince? I'd like to be able to reproduce the apport bug on my system as well.

[Moritz Naumann (mnaumann)]

Here's the document which crashes evince for me. Please note that this document stems from an untrusted source and may well be malicious (so use it in an isolated system only). I have not had a chance to look into it closer, yet. The ZIP password is a single character: the number (digit) 1.

[emptythevoid (emptythevoid)]

Thanks for the link. I couldn't get evince to crash with the PDF file, but I did notice you're using 64-bit, so maybe that's the difference (we're both using evince 3.4.0). I'll have to wait until apport gets called again.

[Moritz Naumann (mnaumann)]

If you just want to trigger apport you can achieve this much more easily:

cat & # Make note of the second field which is the process ID, which I will now reference as "PID"
kill -SIGSEGV PID
fg

Since you no longer need it, I have deleted the apport crash POC.

[emptythevoid (emptythevoid)]

Just now had a slew of GIMP crash reports, but I'll never be able to report them cleanly because apport never displayed any of them in Firefox. Where it stops working as normal is where it's supposed to display the list of stuff to report to the developers. That never happens.

[emptythevoid (emptythevoid)]

This wouldn't be happening because of this "bug/wishlist", would it? It's triaged, right, so no "fix" has been committed, correct? https://bugs.launchpad.net/ubuntu/+source/apport/+bug/196172

[emptythevoid (emptythevoid)]

Thanks for that tip Moritz. That helps me a lot! :)

I rolled back all the installed apport packages from ubuntu7 to ubuntu5, rebooted, and no fix. Also completely removed apport, rebooted, and reinstalled, and no fix.

[emptythevoid (emptythevoid)]

I have tried signing in as different users on the same machine, and calling apport-gtk from the commandline and pointing it to a crash file. It worked as expected, but it still did not open a firefox tab. I tested this on a different computer running 12.04, and it's doing the same thing.

[emptythevoid (emptythevoid)]

I've attached an strace log that I ran when apport was asking to send a bug report but failed to open Firefox. Hopefully this has a clue in it somewhere.

[Neal McBurnett (nealmcb)]

I seem to have a fix for this. And even better, it seems that the reports which are still in /var/crash/*.crash can still be reported.

I started by running this for one of my recent crashes:

$ apport-cli -c /var/crash/_usr_bin_indicator-weather.1000.crash

After entering "s" to "send" the report, nothing happened. So I ran it with pdb:

$ python -m pdb /usr/bin/apport-cli -c ~/info/ubuntu/apport/_usr_bin_indicator-weather.1000.crash

(Pdb) b /usr/lib/python2.7/dist-packages/apport/ui.py:265
(Pdb) s

and discovered that the self.crashdb.accepts(self.report) test was failing.

It works to edit /etc/apport/crashdb.conf and add 'Crash' to the 'problem_types': ['Bug', 'Package', 'Crash'], or to make that change in a separate file and run

$ APPORT_CRASHDB_CONF=~/tmp/crashdb.conf apport-cli -c ~/info/ubuntu/apport/_usr_bin_indicator-weather.1000.crash

I've attached a crashdb.conf that worked for me. But I don't know if it is the right fix.

[emptythevoid (emptythevoid)]

Neal, you sir are brilliant! I copied your crashdb.conf right into the apport folder and it worked like a charm! What do you think caused this issue?

[Moritz Naumann (mnaumann)]

Both python-apport 2.0.1-0ubuntu7 (precise-updates) and 2.0.1-0ubuntu5 (precise) do not list 'Crash' in 'problem_types' in the default /etc/apport/crashdb.conf, and both python-apport 1.23-0ubuntu3 (oneiric) and python-apport 1.23-0ubuntu4 (oneiric-updates) do not have a 'problem_types' declaration (yet). So either adding 'Crash' to this line is correct, which would them seem to indicate that apport crash reports are broken for everyone on Precise (this is an architecture independent package), or, if Canonical is more lucky, this is not a proper fix but just a workaround (but good to have - thanks Neal). Hopefully someone with the needed inside knowledge can spare a minute to comment on this in the not so distant future.

[Logan Rosen (logan)]

I believe that Launchpad crash reports are disabled on purpose, as they now go to the whoopsie database where Ubuntu developers can pick crashes that should be reported and them report them themselves. I wouldn't recommend changing the file manually.

[Neal McBurnett (nealmcb)]

@logan and @moritz, thanks for the hints that this is on purpose. I'm very surprised I hadn't heard about this before, and it wasn't in the Precise release notes. It leaves me wondering how a typcial user can track what happens to their reports, and for that matter, how ubuntu developers can do so.

I just posted what I've dug up about the new ErrorTracker process with whoopsie and daisy (cute names!) at

ErrorTracker: how can I track a bug that caused a crash and was reported via apport / whoopsie? - Ask Ubuntu
 http://askubuntu.com/questions/140379/errortracker-how-can-i-track-a-bug-that-caused-a-crash-and-was-reported-via-app