Bug 1015922 - gdb consumes 100% cpu
gdb consumes 100% cpu
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: abrt (Show other bugs)
20
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: abrt
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-06 16:10 EDT by Resa Drijsen
Modified: 2015-06-29 08:34 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-29 08:34:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot showing gdb cpu usage (1.03 MB, image/png)
2013-10-06 16:10 EDT, Resa Drijsen
no flags Details
abrt error (76.56 KB, image/png)
2013-10-07 03:11 EDT, Resa Drijsen
no flags Details

  None (edit)
Description Resa Drijsen 2013-10-06 16:10:38 EDT
Created attachment 808633 [details]
Screenshot showing gdb cpu usage

Description of problem:
After boot gdb process consumes 100% of 1 CPU.

I am running an up to date version of Fedora 20 x64 in VirtualBox (4.2.18 r88780) with kernel 3.11.3-301.fc20.x86_64 and 2 CPUs.

Version-Release number of selected component (if applicable):
Name        : gdb
Arch        : x86_64
Version     : 7.6.50.20130731
Release     : 12.fc20

How reproducible:
gdb starts consuming 100% of 1 CPU immediately after logging in.


Steps to Reproduce:
Not applicable (see above)

Actual results:
One CPU is contiuously used by gdb

Expected results:
Much lower CPU usage

Additional info:
Attached a screenshot which shows the CPU usage.
The situation seems identical to what is described in bug #911798.
Comment 1 Jan Kratochvil 2013-10-06 16:14:56 EDT
It may be a duplicate of ABRT Bug 995889.
Comment 2 Resa Drijsen 2013-10-06 16:32:42 EDT
(In reply to Jan Kratochvil from comment #1)
> It may be a duplicate of ABRT Bug 995889.

I think you are right. Upon reading the content of bug #995889 I remembered I had a similare issue 2 days ago. Furthermore there were indeed large coredumps in the directory mentioned in the above bug.

After running about 15 minutes the CPU usage dropped back to "normal" and expected level.

Furthermore the mentioned 'abrt-cli list' command gives the following info:
$ sudo abrt-cli list
id f2c402ec67bbe7bea9e40afed334196ef2f0623e
Directory:      /var/tmp/abrt/ccpp-2013-10-06-21:55:51-1132
count:          1
executable:     /usr/bin/gnome-shell
package:        gnome-shell-3.10.0.1-1.fc20
time:           Sun 06 Oct 2013 09:55:51 PM CEST
uid:            42

id f4d5c5e7692007113d8e1b174d98ef5b2267cc14
Directory:      /var/tmp/abrt/ccpp-2013-10-06-21:45:37-1167
executable:     /usr/bin/gnome-shell
package:        gnome-shell-3.10.0.1-1.fc20
time:           Sun 06 Oct 2013 09:45:37 PM CEST
uid:            42

id b33b9ab22e497c0b2fbb98ef57711ce8684b49ae
Directory:      /var/tmp/abrt/ccpp-2013-10-04-11:59:19-1092
count:          1
executable:     /usr/bin/gnome-shell
package:        gnome-shell-3.10.0.1-1.fc20
time:           Fri 04 Oct 2013 11:59:19 AM CEST
uid:            42

id 0e21f6461a5264fcbfd302835cd74ab5f4fa559d
Directory:      /var/tmp/abrt/ccpp-2013-10-04-11:10:38-1011
executable:     /usr/bin/gnome-shell
package:        gnome-shell-3.10.0.1-1.fc20
time:           Fri 04 Oct 2013 11:10:38 AM CEST
uid:            42

Which seems that it was indeed "processing" some bug(s).
Comment 3 Resa Drijsen 2013-10-07 03:11:10 EDT
Created attachment 808737 [details]
abrt error

I believe that this can officially be marked as a duplicate as indicated earlier.
The gdb process was using up 100% CPU during the processing of the error and dropped after the error was shown.
Comment 4 Christian Kujau 2014-01-15 22:02:50 EST
I didn't get a "Backtrace is too big" message, but instead abrt DoS'ed my system after "ksh" produced a coredump. But I only noticed that "abrt-action-generate-core-backtrace" was running after creating the 3rd coredump. Some of these coredumps were 13 MB in size, the last one under 1 MB - yet each abrt-action-generate-core-backtrace process used at least 1G of memory and as much CPU it could get.

This machine has 8G memory and 2 of these processes were killed by the oom-killer (along with some Google Chrome tabs), the last abrt process survived (and just reported bug 1053938).

Is there a way to configure abrt so that only one instance is running (and coredumps are processed sequentially)?
Comment 5 Jan Kratochvil 2014-01-16 11:58:52 EST
This can be fixed in ABRT, Python code has been given in Bug 1015419 Comment 5.
Comment 6 Christian Kujau 2014-01-16 22:24:39 EST
I don't want to derail this bug too much, but I've noticed something else: why is abrt-action-generate-core-backtrace running as root? The coredumps were generated by a user, yet all instances of abrt-action-generate-core-backtrace are running as root, the system was pretty much unusable. ulimits of this particular user would not help here, I guess, because abrt-action-generate-core-backtrace was spawned by "abrtd". Did anyone say "local DoS"? :-)
Comment 7 Jakub Filak 2014-08-22 02:11:00 EDT
(In reply to Christian Kujau from comment #6)
> why is abrt-action-generate-core-backtrace running as root?

Because /proc/sys/kernel/core_pattern runs as root. The core dump hook saves a coredump in an abrt dump directory and asks abrtd to process it.

> Did anyone say "local DoS"? :-)

It's not so easy. You need to create crashes from different binaries because abrtd accepts only one core dump for a single binary per 30s.

Since abrt-2.2.2-2.(fc21,fc22) elfutils is used instead of gdb, so the processing of a single crash should not consume 100%.
Comment 8 Fedora End Of Life 2015-05-29 05:31:38 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 9 Fedora End Of Life 2015-06-29 08:34:21 EDT
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.