nss-mysql-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nss-mysql-devel] Significant memory leak in nss_mysql


From: Matt Peterson
Subject: [Nss-mysql-devel] Significant memory leak in nss_mysql
Date: Tue, 14 May 2002 13:44:03 -0600
User-agent: KMail/1.4.1

Hi,

I was looking at the nss_mysql code today and noticed that for some reason 
calls to strdup() are used to fill out the char* members of the struct passwd 
in _nss_mysql_passwd_fill_struct().

Starting on line 216 of nss-mysql-0.36/passwd.c:

   /* name is stored */
   pw->pw_name = strdup(sql_row[0]);

   .
   .  
   .

   /* storing password */
   pw->pw_passwd = strdup(sql_row[2]);

   .
   .
   .

   /* Realname, empty realname is valid, so no warning */
   pw->pw_gecos = sql_row[3] ? strdup(sql_row[3]) : strdup("");

   .
   . 
   .

These and several more calls are made to strdup() to duplicate strings that 
were obtained via the SQL query.  Hasn't anyone wondered who frees these 
strdup()ed buffers?  The answer appears to be that no one frees them.  I'm 
pretty sure glibc doesn't and most callers of the pwd.h functions don't 
either. 

A fun little exercise (for many reasons) is to write a program that loops over 
a NSS implemented call like getpwnam().  If you use nss_mysql I think you'll 
find it interesting how quickly the process eats memory. 

The function that is called by the nss subsystem of glibc is 

NSS_STATUS _nss_mysql_getpwnam_r (const char *name, struct passwd *result,
                                  char *buf, size_t buflen, int *errnop);

The 'char *buf' and 'size_t buflen' arguments describe the buffer where you 
are supposed to place the strings that the passwd structure points to.  
Therefore, the char* values of result->pw_name, result->pw_passwd, 
result->pw_gecos, result->pw_dir, and result->pw_shell should point to 
locations inside buf (i.e. buf through buf+buflen).  

This way, glibc knows how to appropriately manage memory so that there are not 
leaks regardless of concurrency.



-- 
Matt Peterson
Sr. Software Engineer
Caldera, Inc



reply via email to

[Prev in Thread] Current Thread [Next in Thread]