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 184362 - Memory leak in glibc NIS+ resolver when doing repetitive getpwent calls
Summary: Memory leak in glibc NIS+ resolver when doing repetitive getpwent calls
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc
Version: 3.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
Blocks: RHEL3U8CanFix
TreeView+ depends on / blocked
Reported: 2006-03-08 08:17 UTC by Bastien Nocera
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version: RHBA-2006-0453
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-07-20 14:28:37 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0453 normal SHIPPED_LIVE glibc bug fix update 2006-07-19 18:30:00 UTC

Description Bastien Nocera 2006-03-08 08:17:01 UTC
+++ This bug was initially created as a clone of Bug #174847 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10)
Gecko/20050716 Firefox/1.0.6

Description of problem:
We at VMware, recently came across an issue where our application which uses
glibc API calls (getpwent,getgrent,getpwname,getgrname) showed symptoms of
memory leak. Our team isolated the issue to happen only when the host is
configured to authenticate against a NIS+ server. Our application does a large
number of the above mentioned API calls to get the entire user and group list
for internal use in the application. The configuration where the issue is seen
is when the NIS+ server is configured with 8000 or more users and similar number
of groups. The memory leak is not seen if the local user/group list is
configured similar to the NIS+ server with 8000+ entries. The memory leak soon
(a couple of hours) leads to an out of memory condition which causes the process
to crash and hence our application. For ease of use and test purposes, we have
built a simple utility which is a stripped-down code version of what is
implemented in the application for gathering the user/group data. Similar memory
leak symptoms can be seen with this simple utility as well. I am attaching the
source code of the simple utility.
The hosts were this application has been tested are
1) VMware ESX Server 2.5.1 using GLIBC version 2.2.4-32, version  2.2.4-32.20
2) RHEL Workstation 3.0 U4
3) RHEL Advanced Server 4.0 U2

And we could observe the memory leak in all the cases.

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

How reproducible:

Steps to Reproduce:
1) Configure the NIS+ server with 8000+ users and groups
2) Configure a Linux Host to authenticate against the NIS+ server. [Make the
host a NIS+ client and configure nsswitch.conf to use NIS+]
3) Compile the source code of the simple utility, attached with this email using
gcc [ gcc -o nisMem NISMemoryChecking.c]
4) Open two terminal sessions.
    a) In one terminal session, run the simple utility as
        ./nisMem 0 2
              0 - The first parameter is the maximum loop count [One full
iteration of gathering user/group list]
              2 - The second parameter is the sleep interval between two
consecutive loops
    b) In the other terminal, run top | grep nis.
5) You will soon notice that the memory utilization of the program keeps
constantly rising and never goes down until the application is killed with "^C"
or is terminated through other mechanisms.

Actual Results:  we could observe the memory leak.

Additional info:

Comment 3 Jakub Jelinek 2006-03-14 19:43:48 UTC
contains a so far only very lightly tested backport of the NIS+ fixes to RHEL3

Comment 12 Bob Johnson 2006-04-11 16:26:30 UTC
This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 3.8 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 3.8 release.

Comment 21 Red Hat Bugzilla 2006-07-20 14:28:37 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

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