Description of problem: Trying to report certain failures, the abrt user space tool became unresponsive. Mouse movement was intermittent. Open Office calc suddenly disappeared, as did a few other applications. /var/log/messages shows: abrt-applet invoked oom-killer: gfp_mask=0x201da, order=0, oomkilladj=0 and kernel: Out of memory: kill process 1030 (console-kit-dae) score 521035 or a child kernel: Out of memory: kill process 2968 (run-mozilla.sh) score 125770 or a child kernel: Out of memory: kill process 1731 (rtkit-daemon) score 85194 or a child etc and finally: kernel: Out of memory: kill process 3196 (abrtd) score 49989 or a child After that I bounced the box. This box has 4Gig of ram and about 100G of free disk space. Version-Release number of selected component (if applicable): 12 How reproducible: Just used the user space tool to try to report some failures. I believe it has to do with: abrtd: 45 missing debuginfos, getting package list blah blah blah abrtd: 45 debuginfos can't be found This happened twice and took forever to process. The second one never actually ended. Steps to Reproduce: 1. Use user space tool to report kernel failure and failure with metacity 2. 3. Actual results: Expected results: Additional info: Please consider adding an option at O/S install time to load all required debug libraries if someone volunteers to cooperate with the reporting of failures via the abrt user space tool. Most users have plenty of disk space, so providing an estimate of how much additional space is required would probably allay anyone's fears about using too many resources. That way the long delays are avoided looking for things that aren't already on the system, and the debug data would be complete and more useful to developers.
Thanks for your report and idea! The out-of-memory problem is also reported under 549452 with some examples, so I'm marking this bug as a duplicate. If there is any specific information you can provide (such as any records related to the specific crash that triggered this problem) that would be useful to add to that bug. I am able to report bugs using ABRT without my system crashing, and I have less RAM than you do, so perhaps it is situation-specific in some way. Because it affects a different component, I've re-filed your suggestion to install debuginfo RPMs at install time as Bug 552308. Even though ABRT should function properly when debuginfo RPMs need to be downloaded, it's an option that might be useful for users with intermittent or slow network connections, or who want to make ABRT run as quickly as possible. --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers *** This bug has been marked as a duplicate of bug 549452 ***
Can you run something like: $ ps -A -o pid,comm,args,rss,vsz | sort -n -k4 | tail -20 so that it is visible which processes are especially big?
The next time I get an abort, I'll run that series of commands. I yum update daily and in the last few days the number of abrts has decreased significantly. I don't know what specifically changed, but I used to get several aborts a day, and now I go days before I get one. The failures are usually kernel and firefox. Metacity was involved in the one that led to this incident, but hasn't reappeared since. Now that I think about it the failures are always kernel and firefox at least recently.
If it is gdb, abrt 1.0.4 will have a (largish) limit of frames in the backtrace. We reproduced near-OOM condition when gdb tries to produce a backtrace of SEGVed application which had infinite recursion. The limit removes this OOM scenario.