367374 - Memory leaks in PR Implicit Initialization.

Status: NEW

(NSPR :: NSPR, defect, P5)

Description

[Slavomir Katuscak]

When running Selfserv under Valgrind (Linux), there was detected some memory allocated while init (function PR_Init) and not released while cleanup. Probably it's just problem of selfserv, but it's also possible that it's problem of NSPR.

/usr/bin/valgrind --tool=memcheck --leak-check=yes --show-reachable=yes selfserv -D -p 8443 -d /share/builds/mccrel3/security/securitytip/builds/20070117.1/biarritz_Solaris10_amd64/mozilla/tests_results/security/nssamdrhel3.6/server_memleak -n nssamdrhel3.red.iplanet.com -e nssamdrhel3.red.iplanet.com-ec -w nss -c ABCDEF:C001:C002:C003:C004:C005:C006:C007:C008:C009:C00A:C00B:C00C:C00D:C00E:C00F:C010:C011:C012:C013:C014cdefgijklmnvyz -t 5

==4020== 6 bytes in 1 blocks are still reachable in loss record 2 of 7
==4020==    at 0x442972F: malloc (vg_replace_malloc.c:149)
==4020==    by 0x62A9F9F: strdup (in /lib/tls/libc-2.3.2.so)
==4020==    by 0x4574B36: _PR_InitLinker (prlink.c:321)
==4020==    by 0x457C6DB: _PR_InitStuff (prinit.c:241)
==4020==    by 0x457C714: _PR_ImplicitInitialization (prinit.c:259)
==4020==    by 0x457C741: PR_Init (prinit.c:310)
==4020==    by 0x804E8BD: main (selfserv.c:1684)

==4020== 16 bytes in 1 blocks are still reachable in loss record 3 of 7
==4020==    at 0x442AC82: calloc (vg_replace_malloc.c:279)
==4020==    by 0x45DD500: _dlerror_run (in /lib/libdl-2.3.2.so)
==4020==    by 0x45DCFA3: dlopen@@GLIBC_2.1 (in /lib/libdl-2.3.2.so)
==4020==    by 0x457596C: pr_FindSymbolInProg (prmem.c:130)
==4020==    by 0x45759CD: _PR_InitZones (prmem.c:186)
==4020==    by 0x457C52D: _PR_InitStuff (prinit.c:176)
==4020==    by 0x457C714: _PR_ImplicitInitialization (prinit.c:259)
==4020==    by 0x457C741: PR_Init (prinit.c:310)
==4020==    by 0x804E8BD: main (selfserv.c:1684)

==4020== 2,235 bytes in 5 blocks are still reachable in loss record 6 of 7
==4020==    at 0x442972F: malloc (vg_replace_malloc.c:149)
==4020==    by 0x4576490: PR_Malloc (prmem.c:467)
==4020==    by 0x457C1EF: PR_ErrorInstallTable (prerrortable.c:204)
==4020==    by 0x457BC6B: nspr_InitializePRErrorTable (prerr.c:127)
==4020==    by 0x457C6F9: _PR_InitStuff (prinit.c:248)
==4020==    by 0x457C714: _PR_ImplicitInitialization (prinit.c:259)
==4020==    by 0x457C741: PR_Init (prinit.c:310)
==4020==    by 0x804E8BD: main (selfserv.c:1684)

==4020== 2,968 bytes in 32 blocks are still reachable in loss record 7 of 7
==4020==    at 0x442AC82: calloc (vg_replace_malloc.c:279)
==4020==    by 0x45764F0: PR_Calloc (prmem.c:474)
==4020==    by 0x457455D: _PR_InitTPD (prtpd.c:96)
==4020==    by 0x457C658: _PR_InitStuff (prinit.c:204)
==4020==    by 0x457C714: _PR_ImplicitInitialization (prinit.c:259)
==4020==    by 0x457C741: PR_Init (prinit.c:310)
==4020==    by 0x804E8BD: main (selfserv.c:1684)

Comment 1

[Slavomir Katuscak]

The same problem was detected in Strsclnt.

For all ciphers there were the same 4 leaks, except cipher z - there were 3 new and 1 old leaks:

/usr/bin/valgrind --tool=memcheck --leak-check=yes --show-reachable=yes strsclnt -q -p 8443 -d /share/builds/mccrel3/security/securitytip/builds/20070117.1/biarritz_Solaris10_amd64/mozilla/tests_results/security/nssamdrhel3.6/client_memleak -w nss -c 1000 -C z nssamdrhel3.red.iplanet.com

==10665== 16 bytes in 1 blocks are still reachable in loss record 2 of 19
==10665==    at 0x442AC82: calloc (vg_replace_malloc.c:279)
==10665==    by 0x45DD500: _dlerror_run (in /lib/libdl-2.3.2.so)
==10665==    by 0x45DCFA3: dlopen@@GLIBC_2.1 (in /lib/libdl-2.3.2.so)
==10665==    by 0x457596C: pr_FindSymbolInProg (prmem.c:130)
==10665==    by 0x45759CD: _PR_InitZones (prmem.c:186)
==10665==    by 0x457C52D: _PR_InitStuff (prinit.c:176)
==10665==    by 0x457C714: _PR_ImplicitInitialization (prinit.c:259)
==10665==    by 0x457C741: PR_Init (prinit.c:310)
==10665==    by 0x804E10C: main (strsclnt.c:1341)

==10665== 518 bytes in 15 blocks are still reachable in loss record 11 of 19
==10665==    at 0x442972F: malloc (vg_replace_malloc.c:149)
==10665==    by 0x62A9F9F: strdup (in /lib/tls/libc-2.3.2.so)
==10665==    by 0x456F4A7: PR_NewLogModule (prlog.c:371)
==10665==    by 0x457C540: _PR_InitStuff (prinit.c:185)
==10665==    by 0x457C714: _PR_ImplicitInitialization (prinit.c:259)
==10665==    by 0x457C741: PR_Init (prinit.c:310)
==10665==    by 0x804E10C: main (strsclnt.c:1341)

==10665== 37,450 bytes in 740 blocks are still reachable in loss record 17 of 19
==10665==    at 0x442972F: malloc (vg_replace_malloc.c:149)
==10665==    by 0x4576490: PR_Malloc (prmem.c:467)
==10665==    by 0x4588354: PR_NewCondVar (ptsynch.c:341)
==10665==    by 0x4591096: _PR_InitThreads (ptthread.c:886)
==10665==    by 0x457C6BD: _PR_InitStuff (prinit.c:216)
==10665==    by 0x457C714: _PR_ImplicitInitialization (prinit.c:259)
==10665==    by 0x457C741: PR_Init (prinit.c:310)
==10665==    by 0x804E10C: main (strsclnt.c:1341)

==10665== 123,052 bytes in 1,186 blocks are still reachable in loss record 19 of 19
==10665==    at 0x442AC82: calloc (vg_replace_malloc.c:279)
==10665==    by 0x45764F0: PR_Calloc (prmem.c:474)
==10665==    by 0x456F490: PR_NewLogModule (prlog.c:369)
==10665==    by 0x457C540: _PR_InitStuff (prinit.c:185)
==10665==    by 0x457C714: _PR_ImplicitInitialization (prinit.c:259)
==10665==    by 0x457C741: PR_Init (prinit.c:310)
==10665==    by 0x804E10C: main (strsclnt.c:1341)

Especially last leak is important, because 1,186 blocks is significant number.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

The crucial question here is this:
Are selfserv and strsclnt failing to call PR_Cleanup?
or is PR_Cleanup failing to deallocate these allocations?
or is there some other NSPR function that selfserv and strsclnt 
should be calling to deallocate these allocations?

Comment 3

[Julien Pierre]

Nelson,

I reviewed the selfserv code briefly. There are a number of error cases where it calls "exit", which wouldn't call PR_Cleanup .

Slavo, were those leaks observed in instances of selfserv which had errors ? And if so, what was the return code from the process ?

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Julien, 

IMO, leaks in NSS libraries are high priority, leaks in NSS QA tools are not.  
It's clear that most of NSS's test tools take quick error exits without 
trying to clean up.  We could spend a LOT of time fixing this, but IMO,
there are many other far more important things to do now.
Perhaps we should ask Slavo not to track leaks in test tools that fail.

Comment 5

[Julien Pierre]

Nelson,

I agree in principle and with your P4 assessment, but in order to find library leaks, we rely on the QA tools. So it's in our interest to have the QA tools be as leak-free as possible. But it's certainly lower priority. I believe Slavo has a way to ignore certain leak stacks specifically in his scripts, and it's probably best to do that after we have confirmed that it's a tools leak if it takes too much work to fix the tools.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

In comment 1, valgrind output claims that 123,052 bytes in 1,186 blocks 
were leaked, which were allocated by calls to calloc from PR_NewLogModule.
This information is false on its face.

PR_NewLogModule contains a single allocation call that allocates a struct
containing two pointers and an int.  On a 32-bit system, that struct 
occupies 12 bytes.  That function is called 11 times from a parent function.
Even if it were called 1186 times, rather than 11 times, it still would not
leak 123KB.  1186 x 12 = 14,232, not 123,052.  
Also, 123,052 is not evenly divisible by 1186.  

It's very unfortunate that this output is so unreliable. 

Comment 7

[Slavomir Katuscak]

With new Valgrind options (--leak-resolution=high) stacks looks a bit different, also strange bytes/blocks counting is no more there:

==28701== 6 bytes in 1 blocks are still reachable in loss record 2 of 120
==28701==    at 0x4004405: malloc (vg_replace_malloc.c:149)
==28701==    by 0x60E02F: strdup (in /lib/tls/libc-2.3.4.so)
==28701==    by 0x433AD4C: _PR_InitLinker (prlink.c:321)
==28701==    by 0x43426F2: _PR_InitStuff (prinit.c:241)
==28701==    by 0x434272A: _PR_ImplicitInitialization (prinit.c:259)
==28701==    by 0x434274B: PR_Init (prinit.c:310)
==28701==    by 0x804E9DD: main (selfserv.c:1694)

==28701== 12 bytes in 1 blocks are still reachable in loss record 10 of 120
==28701==    at 0x4004405: malloc (vg_replace_malloc.c:149)
==28701==    by 0x433C6BA: PR_Malloc (prmem.c:467)
==28701==    by 0x434223D: PR_ErrorInstallTable (prerrortable.c:204)
==28701==    by 0x4341CB1: nspr_InitializePRErrorTable (prerr.c:128)
==28701==    by 0x4342710: _PR_InitStuff (prinit.c:248)
==28701==    by 0x434272A: _PR_ImplicitInitialization (prinit.c:259)
==28701==    by 0x434274B: PR_Init (prinit.c:310)
==28701==    by 0x804E9DD: main (selfserv.c:1694)

==28701== 16 bytes in 1 blocks are still reachable in loss record 12 of 120
==28701==    at 0x40056BF: calloc (vg_replace_malloc.c:279)
==28701==    by 0x6F8364: _dlerror_run (in /lib/libdl-2.3.4.so)
==28701==    by 0x6F7D10: dlopen@@GLIBC_2.1 (in /lib/libdl-2.3.4.so)
==28701==    by 0x433BBC0: pr_FindSymbolInProg (prmem.c:130)
==28701==    by 0x433BC27: _PR_InitZones (prmem.c:186)
==28701==    by 0x4342557: _PR_InitStuff (prinit.c:176)
==28701==    by 0x434272A: _PR_ImplicitInitialization (prinit.c:259)
==28701==    by 0x434274B: PR_Init (prinit.c:310)
==28701==    by 0x804E9DD: main (selfserv.c:1694)

==28701== 20 bytes in 1 blocks are still reachable in loss record 19 of 120
==28701==    at 0x40056BF: calloc (vg_replace_malloc.c:279)
==28701==    by 0x433C718: PR_Calloc (prmem.c:474)
==28701==    by 0x433AD2E: _PR_InitLinker (prlink.c:319)
==28701==    by 0x43426F2: _PR_InitStuff (prinit.c:241)
==28701==    by 0x434272A: _PR_ImplicitInitialization (prinit.c:259)
==28701==    by 0x434274B: PR_Init (prinit.c:310)
==28701==    by 0x804E9DD: main (selfserv.c:1694)

==28701== 32 bytes in 1 blocks are still reachable in loss record 30 of 120
==28701==    at 0x40056BF: calloc (vg_replace_malloc.c:279)
==28701==    by 0x433C718: PR_Calloc (prmem.c:474)
==28701==    by 0x43398FA: ExpandMonitorCache (prcmon.c:161)
==28701==    by 0x4339C8D: _PR_InitCMon (prcmon.c:307)
==28701==    by 0x43426DE: _PR_InitStuff (prinit.c:237)
==28701==    by 0x434272A: _PR_ImplicitInitialization (prinit.c:259)
==28701==    by 0x434274B: PR_Init (prinit.c:310)
==28701==    by 0x804E9DD: main (selfserv.c:1694)

==28701== 56 bytes in 1 blocks are still reachable in loss record 43 of 120
==28701==    at 0x40056BF: calloc (vg_replace_malloc.c:279)
==28701==    by 0x433C718: PR_Calloc (prmem.c:474)
==28701==    by 0x434E3BB: PR_NewMonitor (ptsynch.c:457)
==28701==    by 0x4357DE8: _PR_UnixInit (unix.c:2880)
==28701==    by 0x434271A: _PR_InitStuff (prinit.c:254)
==28701==    by 0x434272A: _PR_ImplicitInitialization (prinit.c:259)
==28701==    by 0x434274B: PR_Init (prinit.c:310)
==28701==    by 0x804E9DD: main (selfserv.c:1694)

==28701== 88 bytes in 1 blocks are still reachable in loss record 82 of 120
==28701==    at 0x40056BF: calloc (vg_replace_malloc.c:279)
==28701==    by 0x433C718: PR_Calloc (prmem.c:474)
==28701==    by 0x434D78A: PR_NewLock (ptsynch.c:174)
==28701==    by 0x4357DB6: _PR_UnixInit (unix.c:2878)
==28701==    by 0x434271A: _PR_InitStuff (prinit.c:254)
==28701==    by 0x434272A: _PR_ImplicitInitialization (prinit.c:259)
==28701==    by 0x434274B: PR_Init (prinit.c:310)
==28701==    by 0x804E9DD: main (selfserv.c:1694)

==28701== 88 bytes in 1 blocks are still reachable in loss record 83 of 120
==28701==    at 0x40056BF: calloc (vg_replace_malloc.c:279)
==28701==    by 0x433C718: PR_Calloc (prmem.c:474)
==28701==    by 0x434D78A: PR_NewLock (ptsynch.c:174)
==28701==    by 0x4339C7D: _PR_InitCMon (prcmon.c:306)
==28701==    by 0x43426DE: _PR_InitStuff (prinit.c:237)
==28701==    by 0x434272A: _PR_ImplicitInitialization (prinit.c:259)
==28701==    by 0x434274B: PR_Init (prinit.c:310)
==28701==    by 0x804E9DD: main (selfserv.c:1694)

==28701== 104 bytes in 1 blocks are still reachable in loss record 100 of 120
==28701==    at 0x40056BF: calloc (vg_replace_malloc.c:279)
==28701==    by 0x433C718: PR_Calloc (prmem.c:474)
==28701==    by 0x434E3F1: PR_NewMonitor (ptsynch.c:463)
==28701==    by 0x4357DE8: _PR_UnixInit (unix.c:2880)
==28701==    by 0x434271A: _PR_InitStuff (prinit.c:254)
==28701==    by 0x434272A: _PR_ImplicitInitialization (prinit.c:259)
==28701==    by 0x434274B: PR_Init (prinit.c:310)
==28701==    by 0x804E9DD: main (selfserv.c:1694)

==28701== 128 bytes in 1 blocks are still reachable in loss record 108 of 120
==28701==    at 0x40056BF: calloc (vg_replace_malloc.c:279)
==28701==    by 0x433C718: PR_Calloc (prmem.c:474)
==28701==    by 0x43397C5: ExpandMonitorCache (prcmon.c:112)
==28701==    by 0x4339C8D: _PR_InitCMon (prcmon.c:307)
==28701==    by 0x43426DE: _PR_InitStuff (prinit.c:237)
==28701==    by 0x434272A: _PR_ImplicitInitialization (prinit.c:259)
==28701==    by 0x434274B: PR_Init (prinit.c:310)
==28701==    by 0x804E9DD: main (selfserv.c:1694)

==28701== 448 bytes in 8 blocks are still reachable in loss record 111 of 120
==28701==    at 0x40056BF: calloc (vg_replace_malloc.c:279)
==28701==    by 0x433C718: PR_Calloc (prmem.c:474)
==28701==    by 0x434E3BB: PR_NewMonitor (ptsynch.c:457)
==28701==    by 0x4339801: ExpandMonitorCache (prcmon.c:121)
==28701==    by 0x4339C8D: _PR_InitCMon (prcmon.c:307)
==28701==    by 0x43426DE: _PR_InitStuff (prinit.c:237)
==28701==    by 0x434272A: _PR_ImplicitInitialization (prinit.c:259)
==28701==    by 0x434274B: PR_Init (prinit.c:310)
==28701==    by 0x804E9DD: main (selfserv.c:1694)

==28701== 512 bytes in 1 blocks are still reachable in loss record 112 of 120
==28701==    at 0x40056BF: calloc (vg_replace_malloc.c:279)
==28701==    by 0x433C718: PR_Calloc (prmem.c:474)
==28701==    by 0x433A775: _PR_InitTPD (prtpd.c:96)
==28701==    by 0x4342682: _PR_InitStuff (prinit.c:204)
==28701==    by 0x434272A: _PR_ImplicitInitialization (prinit.c:259)
==28701==    by 0x434274B: PR_Init (prinit.c:310)
==28701==    by 0x804E9DD: main (selfserv.c:1694)

==28701== 832 bytes in 8 blocks are still reachable in loss record 118 of 120
==28701==    at 0x40056BF: calloc (vg_replace_malloc.c:279)
==28701==    by 0x433C718: PR_Calloc (prmem.c:474)
==28701==    by 0x434E3F1: PR_NewMonitor (ptsynch.c:463)
==28701==    by 0x4339801: ExpandMonitorCache (prcmon.c:121)
==28701==    by 0x4339C8D: _PR_InitCMon (prcmon.c:307)
==28701==    by 0x43426DE: _PR_InitStuff (prinit.c:237)
==28701==    by 0x434272A: _PR_ImplicitInitialization (prinit.c:259)
==28701==    by 0x434274B: PR_Init (prinit.c:310)
==28701==    by 0x804E9DD: main (selfserv.c:1694)

These stacks are from strsclnt vs. selfserv tests, from server side (on client looks similar). 

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Now that the leak statistics are reasonable and we have accurate stacks,
this bug is worthy of a higher priority.  It is clearly an NSPR bug.

Comment 10

[Slavomir Katuscak]

This seems to be the same bug, but on different machine (quadcore). This machine was recently added to nightly QA. 

$ uname -a
SunOS quadcore 5.10 Generic_137137-01 sun4v sparc SUNW,T5140

List of PR_Init (direct or indirect) leaks:

Block in use (biu):
Found 8 blocks totaling 896 bytes (21.78% of total; avg block size 112)
At time of each allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewMonitor() at 0xe45299e8 
	[3] ExpandMonitorCache() at 0xe4510f14 
	[4] _PR_InitStuff() at 0xe451dc1c 
	[5] main() at 0x19518 

Block in use (biu):
Found block of size 512 bytes at address 0x427d8 (12.45% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] _PR_InitTPD() at 0xe4511b2c 
	[3] _PR_InitStuff() at 0xe451dbcc 
	[4] main() at 0x19518 

Block in use (biu):
Found 8 blocks totaling 256 bytes (6.22% of total; avg block size 32)
At time of each allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewMonitor() at 0xe45299b8 
	[3] ExpandMonitorCache() at 0xe4510f14 
	[4] _PR_InitStuff() at 0xe451dc1c 
	[5] main() at 0x19518 

Block in use (biu):
Found block of size 132 bytes at address 0x42d18 (3.21% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] ExpandMonitorCache() at 0xe4510ee4 
	[3] _PR_InitStuff() at 0xe451dc1c 
	[4] main() at 0x19518 

Block in use (biu):
Found block of size 112 bytes at address 0x43b08 (2.72% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewMonitor() at 0xe45299e8 
	[3] _PR_UnixInit() at 0xe4532a00 
	[4] main() at 0x19518 

Block in use (biu):
Found block of size 112 bytes at address 0x437b0 (2.72% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewMonitor() at 0xe45299e8 
	[3] PR_NewNamedMonitor() at 0xe4529a64 
	[4] _PR_InitLinker() at 0xe4511ed0 
	[5] _PR_InitStuff() at 0xe451dc3c 
	[6] main() at 0x19518 

Block in use (biu):
Found block of size 88 bytes at address 0x42ad0 (2.14% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewLock() at 0xe4529290 
	[3] _PR_InitStuff() at 0xe451dbec 
	[4] main() at 0x19518 

Block in use (biu):
Found block of size 88 bytes at address 0x42ca8 (2.14% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewLock() at 0xe4529290 
	[3] _PR_InitCMon() at 0xe45113e8 
	[4] _PR_InitStuff() at 0xe451dc1c 
	[5] main() at 0x19518 

Block in use (biu):
Found block of size 88 bytes at address 0x439f0 (2.14% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewLock() at 0xe4529290 
	[3] _PR_InitMW() at 0xe4508874 
	[4] _PR_InitStuff() at 0xe451dc70 
	[5] main() at 0x19518 

Block in use (biu):
Found block of size 88 bytes at address 0x43a60 (2.14% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewLock() at 0xe4529290 
	[3] _PR_UnixInit() at 0xe45329e4 
	[4] main() at 0x19518 

Block in use (biu):
Found block of size 88 bytes at address 0x43910 (2.14% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewLock() at 0xe4529290 
	[3] _PR_InitDtoa() at 0xe4515498 
	[4] _PR_InitStuff() at 0xe451dc60 
	[5] main() at 0x19518 

Block in use (biu):
Found block of size 88 bytes at address 0x43868 (2.14% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewLock() at 0xe4529290 
	[3] _PR_InitStuff() at 0xe451dc44 
	[4] main() at 0x19518 

Block in use (biu):
Found block of size 88 bytes at address 0x43708 (2.14% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewLock() at 0xe4529290 
	[3] _PR_InitLog() at 0xe450c5c8 
	[4] _PR_InitStuff() at 0xe451dc34 
	[5] main() at 0x19518 

Block in use (biu):
Found block of size 88 bytes at address 0x43980 (2.14% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewLock() at 0xe4529290 
	[3] _PR_InitDtoa() at 0xe45154a8 
	[4] _PR_InitStuff() at 0xe451dc60 
	[5] main() at 0x19518 

Block in use (biu):
Found block of size 88 bytes at address 0x43508 (2.14% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewLock() at 0xe4529290 
	[3] _PR_InitFdCache() at 0xe450873c 
	[4] _PR_InitIO() at 0xe452acd8 
	[5] _PR_InitStuff() at 0xe451dc24 
	[6] main() at 0x19518 

Block in use (biu):
Found block of size 88 bytes at address 0x43578 (2.14% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewLock() at 0xe4529290 
	[3] PR_CreateStack() at 0xe4514984 
	[4] _PR_InitFdCache() at 0xe4508748 
	[5] _PR_InitIO() at 0xe452acd8 
	[6] _PR_InitStuff() at 0xe451dc24 
	[7] main() at 0x19518 

Block in use (biu):
Found block of size 88 bytes at address 0x433f0 (2.14% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewLock() at 0xe4529290 
	[3] _PR_InitIO() at 0xe452acac 
	[4] _PR_InitStuff() at 0xe451dc24 
	[5] main() at 0x19518 

Block in use (biu):
Found block of size 88 bytes at address 0x43498 (2.14% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewLock() at 0xe4529290 
	[3] _PR_InitIO() at 0xe452accc 
	[4] _PR_InitStuff() at 0xe451dc24 
	[5] main() at 0x19518 

Block in use (biu):
Found block of size 88 bytes at address 0x42b40 (2.14% of total)
At time of allocation, the call stack was:
	[1] calloc() at 0xdcd42674 
	[2] PR_NewLock() at 0xe4529290 
	[3] _PR_InitThreads() at 0xe4531728 
	[4] _PR_InitStuff() at 0xe451dc0c 
	[5] main() at 0x19518 

Those leaks are visible only in OPT build.

Comment 11

[Slavomir Katuscak]

Updated in list of ignored leaks:

Checking in ignored;
/cvsroot/mozilla/security/nss/tests/memleak/ignored,v  <--  ignored
new revision: 1.74; previous revision: 1.73
done

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Slavo, are you sure that PR_Cleanup is being called ?
If the problem is that PR_Cleanup is not being called, that's not a leak
in NSPR, that's a bug in the program that failed to call PR_Cleanup.
Stacks associated with failure to call PR_Cleanup should not be put together
with stacks due to actual NSPR leaks.  Also, stacks associated with failure
to call PR_Cleanup should have something in them to ensure that those leaks
are only ignored in the program that failed to call PR_Cleanup and not in 
other programs that do call PR_Cleanup.

Comment 13

[Slavomir Katuscak]

Nelson, normally PR_Cleanup is called, but you're right. I just looked to details and I found out that selfserv exited with return code 3, because there was wrong domainname set on machine. In this case PR_Cleanup was not called, so problem is in this case in selfserv (and in machine configuration). DOMSUF was not set and wrong domain was detected. Another interesting info is that when wrong domain is set, tools are crashing with core, should I report this as separate bug ?

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Slavo, please remove the new stacks that you added to "ignored" that were 
actually caused by a failure to call PR_Cleanup.  

Yes, if tools crash with core files due to missing DOMSUF, that is a bug 
worth reporting.

Comment 15

[Slavomir Katuscak]

(In reply to comment #14)
> Slavo, please remove the new stacks that you added to "ignored" that were 
> actually caused by a failure to call PR_Cleanup.  

Removed.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months and this bug has priority 'P2'.
:KaiE, could you have a look please?
For more information, please visit auto_nag documentation.