Bug 1074192 - abrt-action-list-dsos process consuming e.g. 1.5GiB of RAM
Summary: abrt-action-list-dsos process consuming e.g. 1.5GiB of RAM
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Jakub Filak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-08 19:50 UTC by Louise
Modified: 2016-12-01 00:46 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-03-13 23:01:27 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
"maps" file from the /var/tmp/abrt dump directory (50.97 KB, text/plain)
2014-03-10 13:57 UTC, Louise
no flags Details

Description Louise 2014-03-08 19:50:02 UTC
Description of problem:
System has been freezing up lately; I could see that all my RAM was being used, and when I checked "All Processes" (rather than "My Processes") I could see that abrt-action-lis was taking up 1GB or RAM. This has happened a few times during the last week and I have to reboot to recover.

Version-Release number of selected component (if applicable):
2.1.12-2

How reproducible:
Happens daily(?)

Steps to Reproduce:
1.Wait until you notice the system slowing down
2.Check RAM usage and proccesses
3.

Actual results:
abrt using way too much RAM

Expected results:
abrt not using so much RAM

Additional info:

Comment 1 Louise 2014-03-08 20:00:10 UTC
The most recent issue showing in abrt is:
mate-panel killed by SIGSEGV

This occurred about half an hour before I was forced to reboot in the most recent instance.

It says that it "cannot be reported" because "The problem data are incomplete. This usually happens when a problem is detected while computer is shutting down or user is logging out."

Comment 2 Louise 2014-03-10 01:03:51 UTC
Same thing happened again just now ...

When I hover over the "abrt-action-lis" process in System Monitor, it says:
/usr/bin/python -u /usr/bin/abrt-action-list-dsos -m maps -o dso_list

This time it got up to 1.5GiB and then teetered back and forth between 1.5 and 1.4 GiB.

I had to use kill -9
kill -15 was not enough

For the record, abrt never pops up a notification regarding the crash. I opened abrt manually while this was going on and it had registered a crash for gnote this time about 30 minutes prior. after killing the runaway process, I went back into abrt and the gnote crash was no longer there.

Comment 3 Jakub Filak 2014-03-10 09:29:42 UTC
Thank you for the report.

Could you please attach 'maps' file from the dump directory. All dump directories are placed in '/var/tmp/abrt'.

Comment 4 Louise 2014-03-10 13:57:05 UTC
Created attachment 872708 [details]
"maps" file from the /var/tmp/abrt dump directory

Recall that the crash information disappears from abrt after killing the runaway process; there was no dump directory available for the previous crash.

So I caused another crash and retrieved the "maps" file (attached) prior killing the runaway process. The dump directory was deleted after I killed the runaway process.

Comment 5 Jakub Filak 2014-03-10 16:33:49 UTC
Thanks! If you have time to install the following scratch build and re-test, please do so and report the results here.

http://koji.fedoraproject.org/koji/taskinfo?taskID=6617760

Comment 6 Louise 2014-03-13 17:38:23 UTC
Sorry for slow response -- been a little busy ...

Is that build the same as all the abrt updates that just came in through the normal updates repository? If so, the updated packages do not address the issue....

Comment 7 Louise 2014-03-13 23:01:27 UTC
I am no longer able to reproduce the issue ...

It was 100% reproducible before and so far 100% unreproducible now ... I'm not sure what the issue was, but the only significant change I am aware of on my computer between before and now is that I addressed an error I was getting while using yum -- the error message started with: "error: rpmdbNextIterator: skipping h" -- I addressed it by deleting __db.001 - __db.003 and then running rpm --rebuilddb


Note You need to log in before you can comment on or make changes to this bug.