Bug 548058

Summary:	abrtd causes kernel out of memory
Product:	[Fedora] Fedora	Reporter:	Bill Gradwohl <bill>
Component:	abrt	Assignee:	Jiri Moskovcak <jmoskovc>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	low
Version:	12	CC:	anton, beland, dfediuck, dvlasenk, iprikryl, jmoskovc, kklic, mnowak, npajkovs
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-01-04 16:50:35 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Bill Gradwohl 2009-12-16 14:09:46 UTC

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.

Comment 1 Christopher Beland 2010-01-04 16:50:35 UTC

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 ***

Comment 2 Denys Vlasenko 2010-01-05 13:57:20 UTC

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?

Comment 3 Bill Gradwohl 2010-01-05 14:17:14 UTC

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.

Comment 4 Denys Vlasenko 2010-01-05 14:28:56 UTC

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.