Bug 244870 - severe memory leak
severe memory leak
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: setroubleshoot (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: John Dennis
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-19 11:52 EDT by Ulrich Drepper
Modified: 2008-05-14 10:18 EDT (History)
3 users (show)

See Also:
Fixed In Version: 2.0.5-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-14 10:18:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
concatenated /var/log/setroubleshoot/* log files. (3.30 KB, text/plain)
2007-07-04 15:49 EDT, Matěj Cepl
no flags Details

  None (edit)
Description Ulrich Drepper 2007-06-19 11:52:32 EDT
Description of problem:
On my F7 machine which is up for 44 days now setroublshootd is reported to
consume 196M is resident memory.

00601000-1280e000 rw-p 00601000 00:00 0                                  [heap]
Size:            297012 kB
Rss:             195356 kB
Shared_Clean:         0 kB
Shared_Dirty:         0 kB
Private_Clean:      208 kB
Private_Dirty:   195148 kB




Version-Release number of selected component (if applicable):
setroubleshoot-1.9.4-2.fc7.noarch

How reproducible:
no idea

Steps to Reproduce:
1.run F7 machine for some time
2.
3.
  
Actual results:
see above

Expected results:
I see no reason why the heap should ever be more than a few MBs.

Additional info:
Comment 1 John Dennis 2007-06-26 14:34:39 EDT
I wonder if you may be experiencing a known problem with i18n handling which
will cause an exception which may fail to clean up memory. Could you please take
a look at /var/log/setroubleshoot/setroubleshood.log and look for any python
tracebacks (e.g. search for 'trace'). If you find tracebacks could you please
add them to this bugzilla.

If you don't find any tracebacks could you please tell me the size of this file:

/var/lib/setroubleshoot/audit_listener_database.xml

Question: I assume the memory usage output included in the original bug report
was cut and pasted from the output of /proc/pid/smaps, for reasons I do not
undertand on my systems I never see any entry labeled [heap], although there are
a number of anonymous regions, can you shed some light on why /proc/pid/smaps
would not have a [heap] region?
Comment 2 Ulrich Drepper 2007-06-26 14:49:56 EDT
/var/log/setroubleshoot/setroubleshood.log is empty.

# ll /var/lib/setroubleshoot/audit_listener_database.xml
-rw-r--r-- 1 root root 617816 2007-05-13 21:03
/var/lib/setroubleshoot/audit_listener_database.xml

The only reason there could be no [heap] (aside from kernel issues) is that
sbrk() is never used.  Instead malloc is used for allocations.  This should not
happen unless the allocations are too large.

Anyway, this is the current state of the same process (now after 51 days)

00601000-13b33000 rw-p 00601000 00:00 0                                  [heap]
Size:            316616 kB
Rss:             247460 kB
Shared_Clean:         0 kB
Shared_Dirty:         0 kB
Private_Clean:    14200 kB
Private_Dirty:   233260 kB

Still creeping up.
Comment 3 Matěj Cepl 2007-07-04 15:49:09 EDT
Created attachment 158547 [details]
concatenated /var/log/setroubleshoot/* log files.

I have to add big +1 here -- apparently leaking setroubleshootd in couple of
days pushed my two-processor dual-core 1GB RAM computer to the crawl. Only when
it blicked on me in top that setroubleshootd occupies around 540+MB [...] I
killed it and now my comp is happy again.

Attached are /var/log/setroubleshoot/setroubleshoot.* log files and
/var/lib/setroubleshoot/audit_listener_database.xml has 13K. I cannot find it
in any log but when switching to console (the only place, where my computer was
at least slightly responsive) I saw there message something about
/var/lib/setroubleshoot/audit_listener_database.xml containing non-XML
unprintable characters and incorrect CDATA. However, just now xmllint doesn't
complain, so I don't know what it was.
Comment 4 Kim Bisgaard 2007-10-26 11:54:09 EDT
Me too! 345MB

cat /proc/27721/status
Name:   setroubleshootd
State:  S (sleeping)
Tgid:   27721
Pid:    27721
PPid:   1
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 32
Groups: 0 1 2 3 4 6 10
VmPeak:   441896 kB
VmSize:   343584 kB
VmLck:         0 kB
VmHWM:    378248 kB
VmRSS:    312712 kB
VmData:   327696 kB
VmStk:       152 kB
VmExe:         4 kB
VmLib:     12956 kB
VmPTE:       356 kB
StaBrk: 0804a000 kB
Brk:    1b723000 kB
StaStk: bf9a5410 kB
ExecLim:        08049000
Threads:        3
SigQ:   0/15343
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000001001000
SigCgt: 0000000180004007
CapInh: 0000000000000000
CapPrm: 00000000fffffeff
CapEff: 00000000fffffeff
Cpus_allowed:   00000003
Mems_allowed:   1
Comment 5 John Dennis 2007-10-26 12:43:34 EDT
would you please try installing the latest version, setroubleshoot-1.10.7-1.fc8
and see if this resolves your problem. I believe in each of the reported cases
the native language was not english and known bugs have been fixed relating to
i18n handling (which I believe was causing exceptions, which then failed to
clean up after itself).
Comment 6 Kim Bisgaard 2007-10-27 03:09:00 EDT
No improvement!

with 
 Package                 Arch       Version          Repository        Size
=============================================================================
Updating:
 setroubleshoot          noarch     1.10.7-1.fc8     development       100 k
Installing for dependencies:
 setroubleshoot-plugins  noarch     1.10.3-1.fc8     development       474 k
 xdg-utils               noarch     1.0.2-2.fc8      development        51 k
Updating for dependencies:
 setroubleshoot-server   noarch     1.10.7-1.fc8     development       776 k


I get:
 cat /proc/24817/status
Name:   setroubleshootd
State:  S (sleeping)
Tgid:   24817
Pid:    24817
PPid:   1
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 32
Groups: 0 1 2 3 4 6 10
VmPeak:   346824 kB
VmSize:   346824 kB
VmLck:         0 kB
VmHWM:    314436 kB
VmRSS:    314436 kB
VmData:   330212 kB
VmStk:       164 kB
VmExe:         4 kB
VmLib:     13620 kB
VmPTE:       364 kB
StaBrk: 0804a000 kB
Brk:    1b6d1000 kB
StaStk: bf9243a0 kB
ExecLim:        08049000
Threads:        3
SigQ:   0/15343
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000001001000
SigCgt: 0000000180004007
CapInh: 0000000000000000
CapPrm: 00000000fffffeff
CapEff: 00000000fffffeff
Cpus_allowed:   00000003
Mems_allowed:   1

I see no problems in /var/log/setroubleshoot:
cat setroubleshootd.log
2007-10-27 09:05:06,251 [email.WARNING] cannot open file
/var/lib/setroubleshoot/email_alert_recipients, No such file or directory


I think it is related to the size of the audit log file?
 ls -l ../audit/audit.log*
-rw-r----- 1 root root 1917790 2007-10-27 09:05 ../audit/audit.log
-r--r----- 1 root root 5243047 2007-10-24 20:35 ../audit/audit.log.1
-r--r----- 1 root root 5243068 2007-10-17 19:40 ../audit/audit.log.2
-r--r----- 1 root root 5243042 2007-10-09 18:37 ../audit/audit.log.3
Comment 7 Matěj Cepl 2007-10-29 06:06:39 EDT
I can see it as well (BTW, does it matter, that I have x86_64 here):

[matej@hubmaier ~]$ pgrep -f -l setrouble
21179 /usr/bin/python -E /usr/sbin/setroubleshootd
[matej@hubmaier ~]$ cat /proc/21179/status
Name:   setroubleshootd
State:  S (sleeping)
Tgid:   21179
Pid:    21179
PPid:   1
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 64
Groups: 0 1 2 3 4 6 10 
VmPeak:   257120 kB
VmSize:   253836 kB
VmLck:         0 kB
VmHWM:     19824 kB
VmRSS:      9876 kB
VmData:    32568 kB
VmStk:       156 kB
VmExe:         4 kB
VmLib:     13188 kB
VmPTE:       512 kB
StaBrk: 00601000 kB
Brk:    00c45000 kB
StaStk: 7fff6f613fa0 kB
Threads:        3
SigQ:   1/16372
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000001001000
SigCgt: 0000000180004007
CapInh: 0000000000000000
CapPrm: 00000000fffffeff
CapEff: 00000000fffffeff
Cpus_allowed:   00000000,0000000f
Mems_allowed:   00000000,00000001
voluntary_ctxt_switches:        1127822
nonvoluntary_ctxt_switches:     315
[matej@hubmaier ~]$ rpm -q setroubleshoot
setroubleshoot-1.10.7-1.fc8.noarch
[matej@hubmaier ~]$ 
Comment 8 Matěj Cepl 2007-10-29 06:09:28 EDT
Forgot to add:

[matej@hubmaier ~]$ ls -lh /var/lib/setroubleshoot/
celkem 32K
-rw------- 1 root root 25K 2007-10-29 10:34 audit_listener_database.xml
[matej@hubmaier ~]$ ls -lh /var/log/setroubleshoot/setroubleshootd.log*
-rw-r--r-- 1 root root    0 2007-10-28 04:53
/var/log/setroubleshoot/setroubleshootd.log
-rw-r--r-- 1 root root 3,3K 2007-07-04 21:41
/var/log/setroubleshoot/setroubleshootd.log-concatenated
-rw-r--r-- 1 root root    0 2007-09-16 04:57
/var/log/setroubleshoot/setroubleshootd.log.1
-rw-r--r-- 1 root root    0 2007-09-09 04:54
/var/log/setroubleshoot/setroubleshootd.log.2
-rw-r--r-- 1 root root  131 2007-10-16 12:22
/var/log/setroubleshoot/setroubleshootd.log-20071021
-rw-r--r-- 1 root root    0 2007-10-21 04:53
/var/log/setroubleshoot/setroubleshootd.log-20071028
[matej@hubmaier ~]$ 
Comment 9 Bug Zapper 2008-05-14 09:11:56 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 WONTFIX if it remains open with a Fedora 'version' of '7'.

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 prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 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 please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Ulrich Drepper 2008-05-14 10:18:45 EDT
I think this is pretty much under control in F8.

00601000-00efe000 rw-p 00601000 00:00 0                                  [heap]
Size:               9204 kB
Rss:                2156 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:       432 kB
Private_Dirty:      1724 kB
Referenced:         2156 kB

That's after 100 days.

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