Re: [issues] memory leak when invoking openpty

[Maxim Kuvyrkov <maxim@xxxxxxxxxxxxxxxx>]

On 4/16/10 5:17 AM, Zhenhua Zhang wrote:
> Hi Maxim,
>
> On 04/15/2010 08:37 PM, Maxim Kuvyrkov wrote:
> > On 4/14/10 1:35 PM, Zhenhua Zhang wrote:
> > > Hi,
> > >
> > > Valgrind reports definitely lost memory leak when I am invoking
> > > openpty(). Could some one help on that?
> >
> > What is your EGLIBC version?
> >
> > How do you configure your EGLIBC build? It seems that you are using
> > non-default configurations of nsswitch, which exactly option groups are
> > you enabling or disabling?
>
> I am using eglibc (version 2.10.1-0ubuntu15) on Ubuntu 9.10 with default
> configuration. I haven't successfully built eglibc 2.10.1 source yet.
>
> I also tried use __libc_freeres to free all memory holds by the C
> library but it still doesn't work.

The cause of the leak seems to be in nss/getXXbyYY_r.c:
===
int
INTERNAL (REENTRANT_NAME) (ADD_PARAMS, LOOKUP_TYPE *resbuf, char *buffer,
			   size_t buflen, LOOKUP_TYPE **result H_ERRNO_PARM
			   EXTRA_PARAMS)
{
  static bool startp_initialized;
  static service_user *startp;
  static lookup_function start_fct;
...

      /* Make sure start_fct and startp are written before
	 startp_initialized.  */
      atomic_write_barrier ();
      startp_initialized = true;
===

"startp" static variable is a pointer to interpretation of 
/etc/nsswitch.conf.  A similar buffer in nss/getXXbyYY.c is declared 
with __libc_freeres_ptr and, therefore, is handled by __libc_freeres().

The pointer in re-entrant version of the function is not declared with 
__libc_freeres_ptr and, consequently, is not handled by 
__libc_freeres_ptr.  My guess is that it that free()'ing of "startp" 
requires more complicated actions than __libc_freeres() provides (note 
"atomic_write_barrier()" in its initialization).

That said, this memory leak does not seem harmful to me.  It is a 
per-process overhead and it seems to be determined by the size of 
/etc/nsswitch.conf file.

Maybe we should just add a valgrind annotation to avoid valgrind leak 
message?

--
Maxim Kuvyrkov
CodeSourcery
maxim@xxxxxxxxxxxxxxxx
(650) 331-3385 x724