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.
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 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).
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.
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' 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.
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.