Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162119 - slocate / updatedb appears to have a memory leak
Summary: slocate / updatedb appears to have a memory leak
Alias: None
Product: Fedora
Classification: Fedora
Component: libgtop2
Version: 3
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Søren Sandmann Pedersen
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-30 03:32 UTC by David Dunbar
Modified: 2014-06-18 09:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-03-23 16:31:01 UTC

Attachments (Terms of Use)
System monitor output when the /etc/cron.daily/slocate.cron is executed manually. (deleted)
2005-06-30 03:32 UTC, David Dunbar
no flags Details

Description David Dunbar 2005-06-30 03:32:41 UTC
Description of problem:
The daily cron job /etc/cron.daily/slocate.cron does not release memory.

Version-Release number of selected component (if applicable):
Secure Locate 2.7 - Released January 24, 2003

How reproducible:
Memory usage jumps every time the cron job runs, either by the cron job or manually.

Steps to Reproduce:
1. Let the cron job run.
Actual results:
Memory utilization does not drop down after the cron job is done.

Expected results:
The memory utilization should drop,

Additional info:

Comment 1 David Dunbar 2005-06-30 03:32:42 UTC
Created attachment 116160 [details]
System monitor output when the /etc/cron.daily/slocate.cron is executed manually.

Comment 2 Miloslav Trmač 2005-07-03 21:19:06 UTC
Running slocate allocates many entries in the dentry and inode caches,
which are accounted for in the Slab: line of /proc/meminfo.

libgtop2's glibtop_get_mem_s () computes "user" memory as
  MemTotal: - MemFree: - Cached: - Buffer:
(using the /proc/meminfo terminology), which means that the dentry cache
is accounted for as "user" memory.

I'm not quite sure whether just subtracting Slab: from "user" memory is
good enough (some of the memory allocated as Slab: is directly caused
by user-space actions, e.g. opening a file, creating a process), but
I think it still would be an improvement. More detail is available in
/proc/slabinfo if necesary.

Comment 3 Matthew Miller 2006-07-10 20:25:33 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

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