Description of problem: As you may know I had to withdraw the LXDE spin temporarily. The problem itself was a trivial crash of lxde-settings-daemon, but the settings-daemon gets respawned by lxsession automatically. abrt then goes up to 100% CPU and fills the whole overlay of the live OS, until the system finally crashes with a kerneloops. Please set a limit to the number of reports, e. g let abrt only run x times in a y minutes when the crash is the same. Version-Release number of selected component (if applicable): abrt-0.0.11-2.fc12.x86_64
This would be not so easy. Every coredump is initiated by kernel - kernel starts a helper executable so called abrt "hook" and pipes the dump to it. When a few crashes happened at once or one right after another, kernel runs several copies of them. If we want to protect against or ameliorate this, some ideas for CCpp hook: (1) nice ourself? (2) check total size of dump dir, if it overflows, either abort dump or delete oldest/biggest dumps? [abort would be simpler, abrtd already does "delete on overflow" thing] (3) detect parallel dumps in progress and back off (pause/renice further)
I implemented option (2): check total size of dump dir, if it overflows, delete oldest/biggest dump(s) until it fits into configured quota. Should be in next update, 1.0.1. Let me know if you still observe this problem.
The update is now generally available. Christoph, if you'd like to retest and decide whether the solution is working for you, I think you should be able to intentionally induce a crash with "killall -SEGV lxde-settings-daemon". --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
abrt-1.0.3-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/abrt-1.0.3-1.fc12
abrt-1.0.3-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.