Apport should not do its expensive bits without user confirmation

Bug #62542 reported by Dennis Kaarsemaker
2
Affects Status Importance Assigned to Milestone
apport (Ubuntu)
Fix Released
Low
Martin Pitt

Bug Description

Apport should not start collecting data (such as a core dump) before the user agreed to filing a bug report. Otherwise it will waste a huge amount of CPU power on things that may be thrown away. That can also solve bug 61536 and bug 61730

Revision history for this message
Martin Pitt (pitti) wrote :

The core dump is created by the kernel, there is little we can do from stopping it. However, the most expensive part of apport is the collection of package information, not dumping the core usually.

apport itself has no frontend, it creates a report, and apport-gtk picks it up.
Indeed we could move the packaging information collection to the apport frontend, when the user actually agrees to send a report.

Changed in apport:
assignee: nobody → pitti
importance: Undecided → Low
status: Unconfirmed → Confirmed
Revision history for this message
Martin Pitt (pitti) wrote :

OK, let's do that for edgy, after an #u-devel discussion Matt agrees.

I'll move the expensive bits (gdb and dpkg) to apport-gtk and have apport only collect the bare minimum.

Martin Pitt (pitti)
Changed in apport:
status: Confirmed → In Progress
Martin Pitt (pitti)
Changed in apport:
status: In Progress → Fix Committed
Revision history for this message
Martin Pitt (pitti) wrote :

 apport (0.24) edgy; urgency=low
 .
   The "Need for speed" release -- rrrroarrr!
 .
   * apport: Remove _copy_shrink_corefile(): While this has an enormous impact
     on the size of an uncompressed core dump, it only causes a negligible size
     reduction of the bzip2'ed core, but it needs a lot of I/O resources for
     large core dumps.
   * problem_report.py:
     - Use zlib instead of bzip2 for compressing the binary data (in
       particular, core dumps). This results in slightly bigger files, but speeds
       up compression a lot (30 seconds vs. ~2:45 minutes for a Firefox core dump
       on my slow iBook). Closes: LP#61538
     - ProblemReport.read(): Support both bzip2 and zlib compression to be able
       to read existing reports, too.
     - Add/Adapt test cases.
   * Move InformationCollector._get_gdb() from apport to apport_utils.py
     report_add_gdb_info(), and add a test case for it.
   * apport_utils.py, report_add_package_info(): Support calling without a
     package name, then it will be figured out from ExecutableName. Extend test
     case accordingly.
   * test-apport: Do not require apport reports to contain gdb, packaging, and
     OS information, since we are going to move them out of apport.
   * apport: Do not collect static information. It requires a lot of CPU and
     I/O resources and slows down the machine a lot, and it can be added to
     the report later in the frontend. This also gets rid of the entire
     InformationCollector class, since everything has been moved to
     apport_utils.py now. Closes: LP#62542
   * apport: Do not intercept KeyboardInterrupt as unhandled exception (only
     useful for command line debugging, though).
   * problem_report.py: Add test case for appending new data to an existing
     report, fix write() function to not rely on an existing ProblemType key.
   * problem_report.py: Add new method ProblemReport.add_to_existing() to
     update an already existing problem report with new data. Add test case.
   * apport_utils.py, mark_report_seen(): Use os.utime() instead of
     open()/read() and a timeout for simpler and faster operation.
   * gtk/apport-gtk:
     - Collect gdb/packaging/operating system information when the user chooses
       to file a bug and update the apport report.
     - Change the 'Downloading bug patterns...' progress dialog to 'Collecting
       information about the crash...'.
   * debian/control: Bumped library dependencies of apport-gtk, added
     update-notifer dependency.

Changed in apport:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.