Apport can peg CPU for minutes while processing crash report

Bug #1058158 reported by Matthew Paul Thomas on 2012-09-28
34
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Apport
Medium
Unassigned
apport (Ubuntu)
Undecided
Unassigned

Bug Description

apport 2.5.2-0ubuntu4, Ubuntu Q

1. Feed a large crash report to Apport, e.g. by putting the attached 15 MB file into /var/crash/.

What happens: Apport pegs the CPU for several minutes, regardless of what else you're doing.

What should happen, perhaps: There's a limit to how much CPU Apport can use.

This bug report might be Invalid if it is straying into scheduler territory.

Matthew Paul Thomas (mpt) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in apport (Ubuntu):
status: New → Confirmed
Evan (ev) on 2012-11-01
tags: added: whoopsie-daisy
Evan (ev) wrote :

We could set a lower nice value:
http://docs.python.org/2/library/os.html#os.nice

Changed in apport:
importance: Undecided → Medium
status: New → Triaged
Martin Pitt (pitti) wrote :

the kernel pipeline handler already calls os.nice(10). But of course it would still peg the CPU if it is idle, it would just defer if anyone else wants to use it.

Martin Pitt (pitti) wrote :

I. e. I'm not sure what to do about this. Of course we could time out after 15 seconds or so, but then we'd lose the large reports (LibreOffice, gedit with many plugins, or whatnot). We can also look into some optimizations and writing the kernel pipeline in C or with some cpython, but at the end of the day we are getting fed (potentially) some gigabytes of memory dump which we need to compress.

Chad Miller (cmiller) wrote :

This is particularly painful when the compositing or window manager is what crashed. apport-gtk eats all CPU for 90 seconds, during which, there is little or no UI feedback about what's happening and a user would assume that the entire system needs to be rebooted.

From the eons I had to watch the system in a vt, it looks like apport-gtk isn't nice at all. No "N" in process state.

cmiller 29887 10.5 2.7 195012 83720 ? Sl 18:43 0:25 /usr/bin/python3 /usr/share/apport/apport-gtk
cmiller 29894 12.0 2.7 195000 83684 ? Sl 18:43 0:28 /usr/bin/python3 /usr/share/apport/apport-gtk

Some vmstat lines make it look like it's churning on IO.

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r b swpd free buff cache si so bi bo in cs us sy id wa
 2 0 0 227272 158884 1364532 0 0 892 0 767 1568 67 33 0 1
 5 0 0 220800 160412 1367096 0 0 4252 0 1007 2059 68 31 1 1
 2 0 0 213420 160932 1374324 0 0 5352 0 1071 2176 63 36 0 1

One of those apport-gtk threads is off running Python several times to gather information that doesn't change with the process state, like release name. That sort of thing could be deferred and run slowly and nicely so the user can't notice. I don't need to report a crash right *now*, just some time today.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers