If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

memory leak in STAN_RemoveModuleFromDefaultTrustDomain

RESOLVED DUPLICATE of bug 391903

Status

NSS
Libraries
RESOLVED DUPLICATE of bug 391903
10 years ago
9 years ago

People

(Reporter: Boying Lu, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

10 years ago
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
(Reporter)

Comment 1

10 years ago
Created attachment 318754 [details] [diff] [review]
patch
Attachment #318754 - Flags: review?(wtc)

Comment 2

10 years ago
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.
Attachment #318754 - Flags: review?(wtc) → review+
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 391903
(Reporter)

Comment 4

10 years ago
Comment on attachment 318754 [details] [diff] [review]
patch

I've verified that the patch of the bug 391903 has fixed this leak
Attachment #318754 - Attachment is obsolete: true
Version: unspecified → trunk
You need to log in before you can comment on or make changes to this bug.