Apport

apport unkillable in 100% CPU loop

Bug #1986809 reported by Simmo Saan
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Apport
New
Undecided
Unassigned

Bug Description

apport 2.20.11-0ubuntu71.2 somehow created the following process

/usr/bin/python3 /usr/share/apport/apport -p2600077 -s5 -c0 -d1 -P26000077 -u1000 -g1000 -- !usr!share!code!code

which has run at 100% CPU for hours on end.
Somehow SIGKILLing it with root does nothing to stop it.

sudo strace -p 2600349 output is an endless stream of mmaps:

mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22ef22000
munmap(0x7ff22a7fa000, 74612736) = 0
mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22a7fa000
munmap(0x7ff22ef22000, 74612736) = 0
mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22ef22000
munmap(0x7ff22a7fa000, 74612736) = 0
mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22a7fa000
munmap(0x7ff22ef22000, 74612736) = 0
mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22ef22000
munmap(0x7ff22a7fa000, 74612736) = 0
mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22a7fa000
munmap(0x7ff22ef22000, 74612736) = 0
mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22ef22000
munmap(0x7ff22a7fa000, 74612736) = 0
mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22a7fa000
munmap(0x7ff22ef22000, 74612736) = 0
mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22ef22000
munmap(0x7ff22a7fa000, 74612736) = 0
mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22a7fa000
munmap(0x7ff22ef22000, 74612736) = 0
mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22ef22000
munmap(0x7ff22a7fa000, 74612736) = 0
mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22a7fa000
munmap(0x7ff22ef22000, 74612736) = 0
mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22ef22000
munmap(0x7ff22a7fa000, 74612736) = 0
mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22a7fa000
munmap(0x7ff22ef22000, 74612736) = 0
mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22ef22000
munmap(0x7ff22a7fa000, 74612736) = 0
mmap(NULL, 74612736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff22a7fa000

/var/log/apport.log contains nothing for any recent days. /var/crash/ is empty because in a desperate attempt I removed those files, hoping the process would fail, but it didn't.

Revision history for this message
Simmo Saan (sim642) wrote :

I eventually managed to kill the process by attaching gdb to it and killing from gdb.

Revision history for this message
Benjamin Drung (bdrung) wrote :

Thanks for reporting this issue. To further investigate I need either a way to reproduce it or a stacktrace at which point apport were eating up all those CPU cycles. From the logs that you posted, I can see that /usr/share/code/code crashed with signal 5 (SIGTRAP).

Did you experience this behavior the first time? Can you reproduce it?

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

Other bug subscribers

Remote bug watches

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