203764 - Memory leak of 370 bytes from 1 block allocated in copy_environ, due to putenv()/setenv()

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[[e-mail] (gone - use [e-mail] instead)]

Just starting up the latest trunk win32 debug under Purify with -edit, I see:

    [W] MLK: Memory leak of 370 bytes from 1 block allocated in copy_environ
        Distribution of leaked blocks
        Allocation location
        malloc_dbg     [dbgheap.c:164]
        copy_environ   [setenv.c:335]
        _crtsetenv     [setenv.c:98]
        putenv_lk      [putenv.c:161]
        putenv         [putenv.c:78]
        PR_MD_PUT_ENV  [ntmisc.c:54]
        */
        PRIntn _PR_MD_PUT_ENV(const char *name)
        {
     =>     return(putenv(name));
        }
        
        
    PR_SetEnv      [prenv.c:93]
    nsGREDirServiceProvider::AddGRELocationToPath(void)
[nsGREDirServiceProvider.cpp:490]
                                       XPCOM_SEARCH_KEY,
                                       grePath,
                                       path);
     =>   PR_SetEnv(mPathEnvString);
          free(grePath);
        }
        
    nsGREDirServiceProvider::nsGREDirServiceProvider(void)
[nsGREDirServiceProvider.cpp:86]
        nsGREDirServiceProvider::nsGREDirServiceProvider()
        : mPathEnvString(nsnull)
        {
     =>   AddGRELocationToPath();
        }
        
        nsGREDirServiceProvider::~nsGREDirServiceProvider()
    GRE_Startup    [nsXPCOMGlue.cpp:231]
                return rv;
            }
        
     =>     nsGREDirServiceProvider *provider = new nsGREDirServiceProvider();
            if ( !provider ) {
                NS_WARNING("GRE_Startup failed");
                XPCOMGlueShutdown();

Comment 1

[Alec Flett]

huh. I wonder if this leak is unavoidable, or at least that its a libc leak. it
looks like the system is leaking the data in the putenv(), and I'm guessing the
library is the only one with the capability to fix it.

Comment 2

[Doug Turner (:dougt)]

http://lxr.mozilla.org/nspr/source/nsprpub/pr/include/prenv.h#101

i guess, we could reset the env right before we exit.

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

I don't know if this is still valid or not...

Comment 4

[Benjamin Smedberg]

This is not worth fixing. envvar settings must be static, and doing shutdown resets isn't worth the effort.

Comment 5

[Serge Gautherie (:sgautherie)]

I assume bug 114646 was this bug;
and bug 454842 comment 7 testcase is too...