Open
Bug 367384
Opened 17 years ago
Updated 2 years ago
Memory leak in pr_LoadLibraryByPathname.
Categories
(NSPR :: NSPR, defect)
Tracking
(Not tracked)
REOPENED
People
(Reporter: slavomir.katuscak+mozilla, Unassigned)
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)
Comment 1•17 years ago
|
||
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?
Reporter | ||
Comment 2•17 years ago
|
||
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
Reporter | ||
Comment 3•17 years ago
|
||
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)
Comment 4•17 years ago
|
||
The leak in dlopen is almost the same as libc bug 2451 http://sourceware.org/bugzilla/show_bug.cgi?id=2451
Comment 5•17 years ago
|
||
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: 17 years ago
Resolution: --- → INVALID
Comment 6•17 years ago
|
||
Slavo, put the stack traces for this bug into your list of leak stacks to be ignored.
Reporter | ||
Comment 7•17 years ago
|
||
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 → ---
Reporter | ||
Comment 8•17 years ago
|
||
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 **.
Reporter | ||
Comment 9•16 years ago
|
||
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/**
Reporter | ||
Comment 10•16 years ago
|
||
Checking in ignored; /cvsroot/mozilla/security/nss/tests/memleak/ignored,v <-- ignored new revision: 1.65; previous revision: 1.64 done
Comment 11•16 years ago
|
||
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.
Comment 12•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee: wtc → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•