431628 - memory leak in STAN_RemoveModuleFromDefaultTrustDomain

Status: RESOLVED DUPLICATE of bug 391903

(NSS :: Libraries, defect)

Description

[Boying Lu]

I used solaris libumem.so+mdb to detect memory leaks in Thunderbird trunk codes (2008/04/30)
One of the leak I fount is in 
STAN_RemoveModuleFromDefaultTrustDomain()

Re-produce steps:
1. setup some environment variables
   LD_PRELOAD=libumem.so
   UMEM_DEBUG=default
   export LD_PRELOAD UMEM_DEBUG

2 run ./thunderbird-bin under mdb
  mdb ./thunderbird-bin
  ::sysbp _exit
  ::run -P
  quit from TB

3 find leaks in mdb
  ::findleaks

libumem.so will find several leaks, one of them is:            ADDR          BUFADDR        TIMESTAMP           THREAD
                            CACHE          LASTLOG         CONTENTS
         8ce9920          8cebbc0       8b91dfd748                1
                          8076790                0                0
                 libumem.so.1`umem_cache_alloc_debug+0x14f
                 libumem.so.1`umem_cache_alloc+0x144
                 libumem.so.1`umem_alloc+0xc5
                 libumem.so.1`malloc+0x27
                 libnspr4.so`PR_Malloc+0x63
                 libplds4.so`PL_ArenaAllocate+0x203
                 libnss3.so`nss_zalloc_arena_locked+0x73
                 libnss3.so`nss_ZAlloc+0x159
                 libnss3.so`nssSlot_CreateFromPK11SlotInfo+0x4b
                 libnss3.so`nssToken_CreateFromPK11SlotInfo+0x17b
                 libnss3.so`STAN_InitTokenForSlotInfo+0x42
                 libnss3.so`STAN_AddModuleToDefaultTrustDomain+0x51
                 libnss3.so`SECMOD_LoadUserModule+0x68
                 libpipnss.so`void nsNSSComponent::InstallLoadableRoots+0x6e5
                 libpipnss.so`unsigned nsNSSComponent::InitializeNSS+0x8fd


I did a further investigation and found the root cause is in following snippet
in STAN_RemoveModuleFromDefaultTrustDomain()
    if (token) {
            nssToken_NotifyCertsNotVisible(token);
            nssList_Remove(td->tokenList, token);
            PK11Slot_SetNSSToken(module->slots[i], NULL);
            nssToken_Destroy(token);  /** leak here **/
        }

The "token" is destroyed, but the associated slot (i.e. token->slot) is not 
so the token->slot is leaked

Comment 1

[Boying Lu]

Attachment: patch

Comment 2

[Wan-Teh Chang]

Comment on attachment 318754 [details] [diff] [review]
patch

r=wtc.

We probably should add a function for the nssSlot_Destroy +
nssToken_Destroy sequence.  This sequence is also used in the
token_destructor function in trustdomain.c:
http://lxr.mozilla.org/seamonkey/ident?i=token_destructor

A better fix would be to have nssToken_Destroy call nssSlot_Destroy.
But it requires more work.  We'd need to review all callers of
nssToken_Destroy.  The token_destructor function mentioned above
would need to be changed to not call nssSlot_Destroy.

Comment 4

[Boying Lu]

Comment on attachment 318754 [details] [diff] [review]
patch

I've verified that the patch of the bug 391903 has fixed this leak