Red Hat Bugzilla – Bug 1015922
gdb consumes 100% cpu
Last modified: 2015-06-29 08:34:21 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 : 18.104.22.16830731
Release : 12.fc20
gdb starts consuming 100% of 1 CPU immediately after logging in.
Steps to Reproduce:
Not applicable (see above)
One CPU is contiuously used by gdb
Much lower CPU usage
Attached a screenshot which shows the CPU usage.
The situation seems identical to what is described in bug #911798.
It may be a duplicate of ABRT Bug 995889.
(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
time: Sun 06 Oct 2013 09:55:51 PM CEST
time: Sun 06 Oct 2013 09:45:37 PM CEST
time: Fri 04 Oct 2013 11:59:19 AM CEST
time: Fri 04 Oct 2013 11:10:38 AM CEST
Which seems that it was indeed "processing" some bug(s).
Created attachment 808737 [details]
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.
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)?
This can be fixed in ABRT, Python code has been given in Bug 1015419 Comment 5.
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"? :-)
(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%.
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'
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.
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
Thank you for reporting this bug and we are sorry it could not be fixed.