Open Bug 367384 Opened 14 years ago Updated 13 years ago

Memory leak in pr_LoadLibraryByPathname.

Categories

(NSPR :: NSPR, defect)

Product:
NSPR
Component:
NSPR
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
REOPENED

People

(Reporter: slavomir.katuscak+mozilla, Assigned: wtc)

Details

(Keywords: memory-leak) 

While running Selfserv under Valgrind on Linux I found small leak in dlopen() called from pr_LoadLibraryByPathname(). Altough it seems to be a GLIBC problem, maybe we can add some tests if library exists and if permissions are OK, before calling dlopen().

/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== 4 bytes in 1 blocks are definitely lost in loss record 1 of 7
==4020==    at 0x442972F: malloc (vg_replace_malloc.c:149)
==4020==    by 0x41068A2: _dl_map_object_from_fd (in /lib/ld-2.3.2.so)
==4020==    by 0x4104D3C: _dl_map_object (in /lib/ld-2.3.2.so)
==4020==    by 0x633F2E5: dl_open_worker (in /lib/tls/libc-2.3.2.so)
==4020==    by 0x410C895: _dl_catch_error (in /lib/ld-2.3.2.so)
==4020==    by 0x633F141: _dl_open (in /lib/tls/libc-2.3.2.so)
==4020==    by 0x45DCFFA: dlopen_doit (in /lib/libdl-2.3.2.so)
==4020==    by 0x410C895: _dl_catch_error (in /lib/ld-2.3.2.so)
==4020==    by 0x45DD4B5: _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 0x4575126: pr_LoadLibraryByPathname (prlink.c:978)
==4020==    by 0x4574FE4: PR_LoadLibraryWithFlags (prlink.c:580)
Slavo, what are the outputs of "cat /etc/redhat-release" and
"rpm -q glibc" on that Linux machine?

Does the leak also exist on RHEL 4?
This stack was from RHEL3, I'm still tuning script for memleak testing, and there were default values 12 lines of stack on RHEL3 and 4 lines on RHEL4 (I'm going to fix this to see full stacks). Only info I have from RHEL4 is:

==315== 4 bytes in 1 blocks are definitely lost in loss record 1 of 7
==315==    at 0x1B904984: malloc (vg_replace_malloc.c:131)
==315==    by 0x1B8EA3AB: _dl_map_object_from_fd (in /lib/ld-2.3.4.so)
==315==    by 0x1B8EB05B: _dl_map_object (in /lib/ld-2.3.4.so)
==315==    by 0x5FAB57: dl_open_worker (in /lib/tls/libc-2.3.4.so)

Seems to be the same problem.

bash-2.05b$ hostname
nssamdrhel3
bash-2.05b$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 3 (Taroon Update 3)
bash-2.05b$ rpm -q glibc
glibc-2.3.2-95.24
glibc-2.3.2-95.24

bash-3.00$ hostname
nssamdrhel4
bash-3.00$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 1)
bash-3.00$ rpm -q glibc
glibc-2.3.4-2.9
glibc-2.3.4-2.9

Confirmed, it's the same leak, found in both RHEL3 and RHEL4. Full stack is here:

==4630== 4 bytes in 1 blocks are still reachable in loss record 1 of 19
==4630==    at 0x442972F: malloc (vg_replace_malloc.c:149)
==4630==    by 0x41068A2: _dl_map_object_from_fd (in /lib/ld-2.3.2.so)
==4630==    by 0x4104D3C: _dl_map_object (in /lib/ld-2.3.2.so)
==4630==    by 0x633F2E5: dl_open_worker (in /lib/tls/libc-2.3.2.so)
==4630==    by 0x410C895: _dl_catch_error (in /lib/ld-2.3.2.so)
==4630==    by 0x633F141: _dl_open (in /lib/tls/libc-2.3.2.so)
==4630==    by 0x45DCFFA: dlopen_doit (in /lib/libdl-2.3.2.so)
==4630==    by 0x410C895: _dl_catch_error (in /lib/ld-2.3.2.so)
==4630==    by 0x45DD4B5: _dlerror_run (in /lib/libdl-2.3.2.so)
==4630==    by 0x45DCFA3: dlopen@@GLIBC_2.1 (in /lib/libdl-2.3.2.so)
==4630==    by 0x4575126: pr_LoadLibraryByPathname (prlink.c:978)
==4630==    by 0x4574FE4: PR_LoadLibraryWithFlags (prlink.c:580)
==4630==    by 0x63A9E5C: bl_LoadFreeblLibInSoftokenDir (loader.c:218)
==4630==    by 0x63A9ECE: bl_LoadLibrary (loader.c:244)
==4630==    by 0x63A9FA7: freebl_LoadDSO (loader.c:296)
==4630==    by 0x457D078: PR_CallOnce (prinit.c:815)
==4630==    by 0x63AA0B6: freebl_RunLoaderOnce (loader.c:330)
==4630==    by 0x63AB6F9: RNG_RNGInit (loader.c:920)
==4630==    by 0x6390C01: nsc_CommonInitialize (pkcs11.c:3063)
==4630==    by 0x6390E58: NSC_Initialize (pkcs11.c:3156)
==4630==    by 0x44DC396: secmod_ModuleInit (pk11load.c:150)
==4630==    by 0x44DC805: SECMOD_LoadPKCS11Module (pk11load.c:327)
==4630==    by 0x44E73A2: SECMOD_LoadModule (pk11pars.c:323)
==4630==    by 0x44E741A: SECMOD_LoadModule (pk11pars.c:338)
==4630==    by 0x44B573C: nss_Init (nssinit.c:481)
==4630==    by 0x44B59B1: NSS_Initialize (nssinit.c:583)
==4630==    by 0x804E67A: main (strsclnt.c:1441)
==4630== 219 bytes in 1 blocks are still reachable in loss record 10 of 19

There was found also another leak found only in RHEL3 related to dynamic libraries:

==4630==    at 0x442972F: malloc (vg_replace_malloc.c:149)
==4630==    by 0x629989B: vasprintf (in /lib/tls/libc-2.3.2.so)
==4630==    by 0x627EF7C: asprintf (in /lib/tls/libc-2.3.2.so)
==4630==    by 0x45DD3BE: dlerror (in /lib/libdl-2.3.2.so)
==4630==    by 0x4574A19: DLLErrorInternal (prlink.c:246)
==4630==    by 0x45751D4: pr_LoadLibraryByPathname (prlink.c:1115)
==4630==    by 0x4574FE4: PR_LoadLibraryWithFlags (prlink.c:580)
==4630==    by 0x457504D: PR_LoadLibrary (prlink.c:604)
==4630==    by 0x44DC6B5: SECMOD_LoadPKCS11Module (pk11load.c:273)
==4630==    by 0x44F439A: SECMOD_AddModule (pk11util.c:487)
==4630==    by 0x44F4612: SECMOD_AddNewModuleEx (pk11util.c:586)
==4630==    by 0x44F4771: SECMOD_AddNewModule (pk11util.c:626)
==4630==    by 0x44B54E4: nss_FindExternalRoot (nssinit.c:372)
==4630==    by 0x44B57E5: nss_Init (nssinit.c:505)
==4630==    by 0x44B59B1: NSS_Initialize (nssinit.c:583)
==4630==    by 0x804E67A: main (strsclnt.c:1441)


The leak in dlopen is almost the same as libc bug 2451
http://sourceware.org/bugzilla/show_bug.cgi?id=2451
I submitted glibc bug 3889 on the leak in dlerror reported in comment 3:
http://sourceware.org/bugzilla/show_bug.cgi?id=3889

Marked the bug invalid because the leaks are in glibc.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Slavo, put the stack traces for this bug into your list of leak stacks 
to be ignored.
New leaks found related to pr_LoadLibraryByPathname, some of them doesn't use GLIBC functions, so I'm reopening this bug.

==28701== 20 bytes in 1 blocks are still reachable in loss record 17 of 120
==28701==    at 0x40056BF: calloc (vg_replace_malloc.c:279)
==28701==    by 0x433C718: PR_Calloc (prmem.c:474)
==28701==    by 0x433B2C8: pr_LoadLibraryByPathname (prlink.c:862)
==28701==    by 0x433B203: PR_LoadLibraryWithFlags (prlink.c:580)
==28701==    by 0x449127F: sftkdb_LoadFromPath (lgglue.c:146)
==28701==    by 0x44912F9: sftkdb_LoadLibrary (lgglue.c:165)
==28701==    by 0x4491573: sftkdbLoad_Legacy (lgglue.c:280)
==28701==    by 0x4491752: sftkdbCall_ReadSecmodDB (lgglue.c:336)
==28701==    by 0x44B0508: sftkdb_ReadSecmodDB (sftkmod.c:220)
==28701==    by 0x4497E99: NSC_ModuleDBFunc (pkcs11.c:2339)
==28701==    by 0x40BD747: SECMOD_GetModuleSpecList (pk11pars.c:231)
==28701==    by 0x40BDA03: SECMOD_LoadModule (pk11pars.c:332)
==28701==    by 0x4084B8D: nss_Init (nssinit.c:487)
==28701==    by 0x4084DE5: NSS_Initialize (nssinit.c:605)
==28701==    by 0x804F24D: main (selfserv.c:1915)

==28701== 68 bytes in 1 blocks are still reachable in loss record 48 of 120
==28701==    at 0x4004405: malloc (vg_replace_malloc.c:149)
==28701==    by 0x5921D7: _dl_map_object_deps (in /lib/ld-2.3.4.so)
==28701==    by 0x6A1158: dl_open_worker (in /lib/tls/libc-2.3.4.so)
==28701==    by 0x5930FD: _dl_catch_error (in /lib/ld-2.3.4.so)
==28701==    by 0x6A1CB7: _dl_open (in /lib/tls/libc-2.3.4.so)
==28701==    by 0x6F7CB7: dlopen_doit (in /lib/libdl-2.3.4.so)
==28701==    by 0x5930FD: _dl_catch_error (in /lib/ld-2.3.4.so)
==28701==    by 0x6F82BA: _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 0x433B335: pr_LoadLibraryByPathname (prlink.c:978)
==28701==    by 0x433B203: PR_LoadLibraryWithFlags (prlink.c:580)
==28701==    by 0x449127F: sftkdb_LoadFromPath (lgglue.c:146)
==28701==    by 0x44912F9: sftkdb_LoadLibrary (lgglue.c:165)
==28701==    by 0x4491573: sftkdbLoad_Legacy (lgglue.c:280)
==28701==    by 0x4491752: sftkdbCall_ReadSecmodDB (lgglue.c:336)
==28701==    by 0x44B0508: sftkdb_ReadSecmodDB (sftkmod.c:220)
==28701==    by 0x4497E99: NSC_ModuleDBFunc (pkcs11.c:2339)
==28701==    by 0x40BD747: SECMOD_GetModuleSpecList (pk11pars.c:231)
==28701==    by 0x40BDA03: SECMOD_LoadModule (pk11pars.c:332)
==28701==    by 0x4084B8D: nss_Init (nssinit.c:487)
==28701==    by 0x4084DE5: NSS_Initialize (nssinit.c:605)
==28701==    by 0x804F24D: main (selfserv.c:1915)

==28701== 101 bytes in 1 blocks are still reachable in loss record 90 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 0x433B370: pr_LoadLibraryByPathname (prlink.c:1009)
==28701==    by 0x433B203: PR_LoadLibraryWithFlags (prlink.c:580)
==28701==    by 0x449127F: sftkdb_LoadFromPath (lgglue.c:146)
==28701==    by 0x44912F9: sftkdb_LoadLibrary (lgglue.c:165)
==28701==    by 0x4491573: sftkdbLoad_Legacy (lgglue.c:280)
==28701==    by 0x4491752: sftkdbCall_ReadSecmodDB (lgglue.c:336)
==28701==    by 0x44B0508: sftkdb_ReadSecmodDB (sftkmod.c:220)
==28701==    by 0x4497E99: NSC_ModuleDBFunc (pkcs11.c:2339)
==28701==    by 0x40BD747: SECMOD_GetModuleSpecList (pk11pars.c:231)
==28701==    by 0x40BDA03: SECMOD_LoadModule (pk11pars.c:332)
==28701==    by 0x4084B8D: nss_Init (nssinit.c:487)
==28701==    by 0x4084DE5: NSS_Initialize (nssinit.c:605)
==28701==    by 0x804F24D: main (selfserv.c:1915)

==28701== 101 bytes in 1 blocks are still reachable in loss record 91 of 120
==28701==    at 0x4004405: malloc (vg_replace_malloc.c:149)
==28701==    by 0x59046F: _dl_new_object (in /lib/ld-2.3.4.so)
==28701==    by 0x58C5B8: _dl_map_object_from_fd (in /lib/ld-2.3.4.so)
==28701==    by 0x58E0BB: _dl_map_object (in /lib/ld-2.3.4.so)
==28701==    by 0x6A10F7: dl_open_worker (in /lib/tls/libc-2.3.4.so)
==28701==    by 0x5930FD: _dl_catch_error (in /lib/ld-2.3.4.so)
==28701==    by 0x6A1CB7: _dl_open (in /lib/tls/libc-2.3.4.so)
==28701==    by 0x6F7CB7: dlopen_doit (in /lib/libdl-2.3.4.so)
==28701==    by 0x5930FD: _dl_catch_error (in /lib/ld-2.3.4.so)
==28701==    by 0x6F82BA: _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 0x433B335: pr_LoadLibraryByPathname (prlink.c:978)
==28701==    by 0x433B203: PR_LoadLibraryWithFlags (prlink.c:580)
==28701==    by 0x449127F: sftkdb_LoadFromPath (lgglue.c:146)
==28701==    by 0x44912F9: sftkdb_LoadLibrary (lgglue.c:165)
==28701==    by 0x4491573: sftkdbLoad_Legacy (lgglue.c:280)
==28701==    by 0x4491752: sftkdbCall_ReadSecmodDB (lgglue.c:336)
==28701==    by 0x44B0508: sftkdb_ReadSecmodDB (sftkmod.c:220)
==28701==    by 0x4497E99: NSC_ModuleDBFunc (pkcs11.c:2339)
==28701==    by 0x40BD747: SECMOD_GetModuleSpecList (pk11pars.c:231)
==28701==    by 0x40BDA03: SECMOD_LoadModule (pk11pars.c:332)
==28701==    by 0x4084B8D: nss_Init (nssinit.c:487)
==28701==    by 0x4084DE5: NSS_Initialize (nssinit.c:605)
==28701==    by 0x804F24D: main (selfserv.c:1915)

==28701== 101 bytes in 1 blocks are still reachable in loss record 92 of 120
==28701==    at 0x4004405: malloc (vg_replace_malloc.c:149)
==28701==    by 0x58B946: expand_dynamic_string_token (in /lib/ld-2.3.4.so)
==28701==    by 0x58E032: _dl_map_object (in /lib/ld-2.3.4.so)
==28701==    by 0x6A10F7: dl_open_worker (in /lib/tls/libc-2.3.4.so)
==28701==    by 0x5930FD: _dl_catch_error (in /lib/ld-2.3.4.so)
==28701==    by 0x6A1CB7: _dl_open (in /lib/tls/libc-2.3.4.so)
==28701==    by 0x6F7CB7: dlopen_doit (in /lib/libdl-2.3.4.so)
==28701==    by 0x5930FD: _dl_catch_error (in /lib/ld-2.3.4.so)
==28701==    by 0x6F82BA: _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 0x433B335: pr_LoadLibraryByPathname (prlink.c:978)
==28701==    by 0x433B203: PR_LoadLibraryWithFlags (prlink.c:580)
==28701==    by 0x449127F: sftkdb_LoadFromPath (lgglue.c:146)
==28701==    by 0x44912F9: sftkdb_LoadLibrary (lgglue.c:165)
==28701==    by 0x4491573: sftkdbLoad_Legacy (lgglue.c:280)
==28701==    by 0x4491752: sftkdbCall_ReadSecmodDB (lgglue.c:336)
==28701==    by 0x44B0508: sftkdb_ReadSecmodDB (sftkmod.c:220)
==28701==    by 0x4497E99: NSC_ModuleDBFunc (pkcs11.c:2339)
==28701==    by 0x40BD747: SECMOD_GetModuleSpecList (pk11pars.c:231)
==28701==    by 0x40BDA03: SECMOD_LoadModule (pk11pars.c:332)
==28701==    by 0x4084B8D: nss_Init (nssinit.c:487)
==28701==    by 0x4084DE5: NSS_Initialize (nssinit.c:605)
==28701==    by 0x804F24D: main (selfserv.c:1915)

==28701== 112 bytes in 1 blocks are still reachable in loss record 101 of 120
==28701==    at 0x40056BF: calloc (vg_replace_malloc.c:279)
==28701==    by 0x59453F: _dl_check_map_versions (in /lib/ld-2.3.4.so)
==28701==    by 0x6A11CB: dl_open_worker (in /lib/tls/libc-2.3.4.so)
==28701==    by 0x5930FD: _dl_catch_error (in /lib/ld-2.3.4.so)
==28701==    by 0x6A1CB7: _dl_open (in /lib/tls/libc-2.3.4.so)
==28701==    by 0x6F7CB7: dlopen_doit (in /lib/libdl-2.3.4.so)
==28701==    by 0x5930FD: _dl_catch_error (in /lib/ld-2.3.4.so)
==28701==    by 0x6F82BA: _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 0x433B335: pr_LoadLibraryByPathname (prlink.c:978)
==28701==    by 0x433B203: PR_LoadLibraryWithFlags (prlink.c:580)
==28701==    by 0x449127F: sftkdb_LoadFromPath (lgglue.c:146)
==28701==    by 0x44912F9: sftkdb_LoadLibrary (lgglue.c:165)
==28701==    by 0x4491573: sftkdbLoad_Legacy (lgglue.c:280)
==28701==    by 0x4491752: sftkdbCall_ReadSecmodDB (lgglue.c:336)
==28701==    by 0x44B0508: sftkdb_ReadSecmodDB (sftkmod.c:220)
==28701==    by 0x4497E99: NSC_ModuleDBFunc (pkcs11.c:2339)
==28701==    by 0x40BD747: SECMOD_GetModuleSpecList (pk11pars.c:231)
==28701==    by 0x40BDA03: SECMOD_LoadModule (pk11pars.c:332)
==28701==    by 0x4084B8D: nss_Init (nssinit.c:487)
==28701==    by 0x4084DE5: NSS_Initialize (nssinit.c:605)
==28701==    by 0x804F24D: main (selfserv.c:1915)

==28701== 689 bytes in 1 blocks are still reachable in loss record 116 of 120
==28701==    at 0x40056BF: calloc (vg_replace_malloc.c:279)
==28701==    by 0x5901F0: _dl_new_object (in /lib/ld-2.3.4.so)
==28701==    by 0x58C5B8: _dl_map_object_from_fd (in /lib/ld-2.3.4.so)
==28701==    by 0x58E0BB: _dl_map_object (in /lib/ld-2.3.4.so)
==28701==    by 0x6A10F7: dl_open_worker (in /lib/tls/libc-2.3.4.so)
==28701==    by 0x5930FD: _dl_catch_error (in /lib/ld-2.3.4.so)
==28701==    by 0x6A1CB7: _dl_open (in /lib/tls/libc-2.3.4.so)
==28701==    by 0x6F7CB7: dlopen_doit (in /lib/libdl-2.3.4.so)
==28701==    by 0x5930FD: _dl_catch_error (in /lib/ld-2.3.4.so)
==28701==    by 0x6F82BA: _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 0x433B335: pr_LoadLibraryByPathname (prlink.c:978)
==28701==    by 0x433B203: PR_LoadLibraryWithFlags (prlink.c:580)
==28701==    by 0x449127F: sftkdb_LoadFromPath (lgglue.c:146)
==28701==    by 0x44912F9: sftkdb_LoadLibrary (lgglue.c:165)
==28701==    by 0x4491573: sftkdbLoad_Legacy (lgglue.c:280)
==28701==    by 0x4491752: sftkdbCall_ReadSecmodDB (lgglue.c:336)
==28701==    by 0x44B0508: sftkdb_ReadSecmodDB (sftkmod.c:220)
==28701==    by 0x4497E99: NSC_ModuleDBFunc (pkcs11.c:2339)
==28701==    by 0x40BD747: SECMOD_GetModuleSpecList (pk11pars.c:231)
==28701==    by 0x40BDA03: SECMOD_LoadModule (pk11pars.c:332)
==28701==    by 0x4084B8D: nss_Init (nssinit.c:487)
==28701==    by 0x4084DE5: NSS_Initialize (nssinit.c:605)
==28701==    by 0x804F24D: main (selfserv.c:1915)
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Currently this bug was found with these stacks (in both selfserv and strsclnt):

main/NSS_Initialize/nss_Init/SECMOD_LoadModule/SECMOD_GetModuleSpecList/NSC_ModuleDBFunc/sftkdb_ReadSecmodDB/sftkdbCall_ReadSecmodDB/sftkdbLoad_Legacy/sftkdb_LoadLibrary/sftkdb_LoadFromPath/PR_LoadLibraryWithFlags/pr_LoadLibraryByPathname/**
main/NSS_Initialize/nss_Init/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/PR_CallOnce/softoken_LoadDSO/loader_LoadLibrary/loader_LoadLibInReferenceDir/PR_LoadLibraryWithFlags/pr_LoadLibraryByPathname/**
main/NSS_Initialize/nss_Init/SECMOD_LoadModule/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/PR_LoadLibrary/PR_LoadLibraryWithFlags/pr_LoadLibraryByPathname/**
main/NSS_Initialize/nss_Init/SECMOD_LoadModule/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/secmod_ModuleInit/NSC_Initialize/nsc_CommonInitialize/RNG_RNGInit/freebl_RunLoaderOnce/PR_CallOnce/freebl_LoadDSO/loader_LoadLibrary/loader_LoadLibInReferenceDir/PR_LoadLibraryWithFlags/pr_LoadLibraryByPathname/**
main/NSS_Initialize/nss_Init/SECMOD_LoadModule/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/secmod_ModuleInit/FC_Initialize/nsc_CommonInitialize/RNG_RNGInit/freebl_RunLoaderOnce/PR_CallOnce/freebl_LoadDSO/loader_LoadLibrary/loader_LoadLibInReferenceDir/PR_LoadLibraryWithFlags/pr_LoadLibraryByPathname/**

In most of them with PR_Calloc/calloc, strdup/malloc or dlopen@@GLIBC_2.1 instead of **. 
Last 3 days I see new leak reported in nightly tests on Solaris. When I analyzed logs, I found out that some stacks of this leak have changed (some functions are skipped), but actually it's still the same leak.

List of stacks related to this bug before change:
IGNORED STACK (#367384): selfserv/main/NSS_Initialize/nss_Init/SECMOD_LoadModule/SECMOD_GetModuleSpecList/NSC_ModuleDBFunc/sftkdb_ReadSecmodDB/sftkdbCall_ReadSecmodDB/sftkdb_LoadLibrary/PR_LoadLibraryWithFlags/pr_LoadLibraryByPathname/PR_Calloc/calloc
IGNORED STACK (#367384): selfserv/main/NSS_Initialize/nss_Init/SECMOD_LoadModule/SECMOD_GetModuleSpecList/NSC_ModuleDBFunc/sftkdb_ReadSecmodDB/sftkdbCall_ReadSecmodDB/sftkdb_LoadLibrary/PR_LoadLibraryWithFlags/pr_LoadLibraryByPathname/_strdup
IGNORED STACK (#367384): selfserv/main/NSS_Initialize/nss_Init/SECMOD_LoadModule/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/NSC_Initialize/RNG_RNGInit/PR_CallOnce/freebl_LoadDSO/PR_LoadLibraryWithFlags/pr_LoadLibraryByPathname/PR_Calloc/calloc
IGNORED STACK (#367384): selfserv/main/NSS_Initialize/nss_Init/SECMOD_LoadModule/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/NSC_Initialize/RNG_RNGInit/PR_CallOnce/freebl_LoadDSO/PR_LoadLibraryWithFlags/pr_LoadLibraryByPathname/_strdup
IGNORED STACK (#367384): selfserv/main/NSS_Initialize/nss_Init/SECMOD_LoadModule/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/PR_LoadLibrary/pr_LoadLibraryByPathname/PR_Calloc/calloc
IGNORED STACK (#367384): selfserv/main/NSS_Initialize/nss_Init/SECMOD_LoadModule/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/PR_LoadLibrary/pr_LoadLibraryByPathname/_strdup
IGNORED STACK (#367384): selfserv/main/NSS_Initialize/nss_Init/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/PR_CallOnce/softoken_LoadDSO/PR_LoadLibraryWithFlags/pr_LoadLibraryByPathname/PR_Calloc/calloc
IGNORED STACK (#367384): selfserv/main/NSS_Initialize/nss_Init/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/PR_CallOnce/softoken_LoadDSO/PR_LoadLibraryWithFlags/pr_LoadLibraryByPathname/_strdup

List of stacks related to this bug after change:
IGNORED STACK (#367384): selfserv/main/NSS_Initialize/SECMOD_LoadModule/SECMOD_GetModuleSpecList/NSC_ModuleDBFunc/sftkdb_ReadSecmodDB/sftkdbCall_ReadSecmodDB/sftkdbLoad_Legacy/PR_LoadLibraryWithFlags/PR_Calloc/calloc
IGNORED STACK (#367384): selfserv/main/NSS_Initialize/SECMOD_LoadModule/SECMOD_GetModuleSpecList/NSC_ModuleDBFunc/sftkdb_ReadSecmodDB/sftkdbCall_ReadSecmodDB/sftkdbLoad_Legacy/PR_LoadLibraryWithFlags/_strdup
NEW STACK: selfserv/main/NSS_Initialize/SECMOD_LoadModule/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/PR_LoadLibrary/PR_Calloc/calloc
NEW STACK: selfserv/main/NSS_Initialize/SECMOD_LoadModule/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/PR_LoadLibrary/_strdup
IGNORED STACK (#367384): selfserv/main/NSS_Initialize/SECMOD_LoadModule/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/secmod_ModuleInit/NSC_Initialize/RNG_RNGInit/PR_CallOnce/freebl_LoadDSO/PR_LoadLibraryWithFlags/PR_Calloc/calloc
IGNORED STACK (#367384): selfserv/main/NSS_Initialize/SECMOD_LoadModule/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/secmod_ModuleInit/NSC_Initialize/RNG_RNGInit/PR_CallOnce/freebl_LoadDSO/PR_LoadLibraryWithFlags/_strdup
IGNORED STACK (#367384): selfserv/main/NSS_Initialize/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/PR_CallOnce/softoken_LoadDSO/PR_LoadLibraryWithFlags/PR_Calloc/calloc
IGNORED STACK (#367384): selfserv/main/NSS_Initialize/SECMOD_LoadModule/SECMOD_LoadPKCS11Module/PR_CallOnce/softoken_LoadDSO/PR_LoadLibraryWithFlags/_strdup

Two stacks are not detected, because pr_LoadLibraryByPathname is missing there and PR_Calloc and _strdup are called directly from PR_LoadLibrary. This can be cause probably by some optimalization options or change/upgrade of compiler or other code changes (but I don't see in CVS anything that can affect this).

I'm adding to ignored leaks file new line to match also stacks that are not detected yet:
**/PR_LoadLibrary/**


Checking in ignored;
/cvsroot/mozilla/security/nss/tests/memleak/ignored,v  <--  ignored
new revision: 1.65; previous revision: 1.64
done
I believe Christophe may have upgraded the compiler for some of our nightly builds to studio 12. This could change the stacks, particularly in optimized builds.
You need to log in before you can comment on or make changes to this bug.