DanKegel wrote, On 2009-03-15 11:50:
> I'm looking at memory leaks, starting with the simple test program
>
> #include <ssl.h>
> #include <stdio.h>
> int main()
> {
> NSS_NoDB_Init();
> NSS_Shutdown();
For leak testing, there's one more important call to be placed here.
PR_Cleanup();
> }
NSPR in implicitly initialized but must be explicitly shutdown to
ensure no leaks.
Also, when doing leak testing, you will not get accurate leak stacks
from the various leak tools unless your test programs run with the
environment variable
NSS_DISABLE_ARENA_FREE_LIST=1
This is because NSS and NSPR have an allocator that recycles allocated
memory on a free list. These get allocated and freed many times in NSS
but most of those times, the "free" actually just puts it on a free list
rather than actually freeing back to the heap. Consequently, if such a
block actually is leaked by some block of code that got it from the free
list, the allocation stack captured by malloc will be for the first block
of code that allocated it from the heap, (which may well have not leaked
it), rather than showing the block of code that actually allocated the
leaked block from the free list and then leaked it. So, to get accurate
leak stacks, it is necessary to disable this free list, causing all frees to
actually free back to the heap.
NSS clears the free list during shutdown, so the free list won't create
any new leaks, but it does cause the reported leak stacks to be wrong.
> This shows two leaks right now, but should show none, right?
What versions of NSS and NSPR are you using? Also, if you're using a
version that is part of a Linux distro, which Linux distro does it
come from?
Sadly, some of the Linux distros really change NSS, so we can only accept
reports about leaks if they are found using Mozilla's NSS, or an NSS built
from Mozilla's sources.
> The first leak was mentioned by wtc in
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=2451
> and shows up for me like this:
>
> 4 bytes in 1 blocks are definitely lost in loss record 1 of 6
> at malloc (vg_replace_malloc.c:207)
> by _dl_map_object_from_fd (in /lib32/ld-2.8.90.so)
> ...
> by dlopen@@GLIBC_2.1 (in /lib32/libdl-2.8.90.so)
> by pr_LoadLibraryByPathname (prlink.c:984)
This leak is believed to be in GLIBC, not by any fault of NSS, IIRC.
I believe this particular leak is the subject of
https://bugzilla.mozilla.org/show_bug.cgi?id=367384
We have a file of known leak stacks that occur in our testing.
Quite a number of those leaks are believed to be the fault of the
underlying OS's library files, not of NSS or NSPR. You can see this
list (for the tip of the trunk) at
http://mxr.mozilla.org/security/source/security/nss/tests/memleak/ignored
It includes a short-hand of the relevant stacks, and the bug number from
bugzilla.mozilla.org that contains the relevant info.
> The second leak is:
>
> 72 bytes in 1 blocks are definitely lost in loss record 4 of 6
> at calloc (vg_replace_malloc.c:397)
> by PR_Calloc (prmem.c:474)
> by error_get_my_stack (error.c:141)
> by nss_ClearErrorStack (error.c:277)
> by NSSArena_Create (arena.c:385)
> by NSSTrustDomain_Create (trustdomain.c:74)
> by STAN_LoadDefaultNSS3TrustDomain (pki3hack.c:141)
> by nss_Init (nssinit.c:553)
> by NSS_NoDB_Init (nssinit.c:700)
> by main (foo.c:7)
There were a bunch of leaks involving NSS "Error stacks". Most of them
were fixed in 3.12.1, and we believe all of them are fixed in 3.12.2.
See
<https://bugzilla.mozilla.org/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bugidtype=include&chfield=%5BBug%20creation%5D&chfieldfrom=2004-11-08&chfieldto=Now&long_desc=error_get_my_stack&long_desc_type=substring&product=NSS>
It's possible that this is a case of the wrong leak stack being reported.
If so, your results will change when you set
NSS_DISABLE_ARENA_FREE_LIST=1
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
