Bug 56662 - getservbyname leaks memory on failure
getservbyname leaks memory on failure
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.1
alphaev6 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-23 12:46 EST by Andrew Schultz
Modified: 2016-11-24 10:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-12-15 13:19:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew Schultz 2001-11-23 12:46:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:0.9.6) Gecko/20011120

Description of problem:
if getservbyname is called, and fails to match the service/protocol to
something in the local database, memory is leaked.  Even if the
service/protocol is found as a yp/nis entry, memory is still leaked.

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


How reproducible:
Always

Steps to Reproduce:
1.call getservbyname with an invalid service/protocol
2.memory is leaked
3.
	

Actual Results:  memory should not be leaked.

Expected Results:  virtual memory footprint grows by about 112 bytes per call.

Additional info:

/* This program prints out its own growth since inception. *
 * using glibc-2.2.4-19, the output is:                    *
 * 100 516096                                              *
 * 200 524288                                              *
 * 300 532480                                              *
 * 400 548864                                              *
 * 500 557056                                              *
 * 600 573440                                              *
 * 700 581632                                              *
 * 800 589824                                              *
 * 900 606208                                              *
 * 1000 614400                                             */

#include <stdlib.h>
#include <stdio.h>
#include <netdb.h>
#include <sys/types.h>
#include <unistd.h>

int main( void )
{
   int i, j, m, m0;
   struct servent *s;
   pid_t mypid;
   char fn[20], t[22][20];
   char l[400];
   FILE *fp;

   s = getservbyname( "ftp", "tcp");
   mypid=getpid();
   sprintf (fn,"/proc/%d/stat",mypid);
   fp=fopen(fn,"r");
   fgets(l, 398, fp);
   sscanf(l,"%s %s %s %s %s %s %s %s %s %s %s %s %s %s %s %s %s %s 
       %s %s %s %s %d",t[1],t[2],t[3],t[4],t[5],t[6],t[7],t[8],
       t[9],t[10],t[11],t[12],t[13],t[14],t[15],t[16],t[17],t[18],
       t[19],t[20],t[21],t[22],&m0);
   fclose (fp);
   for( i=0; i<10; i++)
   {
      for (j=0; j<100; j++)
      {
	 s = getservbyname( "foobar", "tcp");
	 usleep (100000UL);
      }
      fp=fopen(fn,"r");
      fgets(l, 399, fp);
      sscanf(l,"%s %s %s %s %s %s %s %s %s %s %s %s %s %s %s %s %s
          %s %s %s %s %s %d",t[1],t[2],t[3],t[4],t[5],t[6],t[7],t[8],
          t[9],t[10],t[11],t[12],t[13],t[14],t[15],t[16],t[17],t[18],
          t[19],t[20],t[21],t[22],&m);
      fclose (fp);
      printf ("%d %d\n", (i+1)*100, m-m0);
   }

   return 0;
}
Comment 1 Jakub Jelinek 2001-11-28 11:58:05 EST
Cannot reproduce this with glibc-2.2.4-19 on i686 nor alpha.
I even tried to just call while(1) s = getservbyname( "foobar", "tcp");
but even that didn't show any memory leakage (both without and with nscd).
Comment 2 Andrew Schultz 2001-11-28 14:04:12 EST
After further testing, the problem only occurs if ypbind is running.  If ypbind
is not running, output looks like:

> 100 458752
> 200 466944
> 300 466944
> 400 466944
> 500 466944
> 600 466944
> 700 466944
> 800 466944
> 900 466944
> 1000 466944

we are running ypbind-1.7-8.  Simply removing "yp" from the services entry in
svc.conf has no effect.
Comment 3 Andrew Schultz 2002-08-01 19:30:17 EDT
this is now working fine with updated packages installed
(glibc-2.2.4-24 and 2.2.4-27)

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