Bug 1039062 - Memory leak in SECMOD_LoadModule
Summary: Memory leak in SECMOD_LoadModule
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nss
Version: 6.5
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: pre-dev-freeze
: ---
Assignee: Bob Relyea
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 1087920
TreeView+ depends on / blocked
 
Reported: 2013-12-06 14:06 UTC by Hubert Kario
Modified: 2016-07-27 08:50 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1087920 (view as bug list)
Environment:
Last Closed: 2016-07-27 08:50:00 UTC
Target Upstream Version:


Attachments (Terms of Use)
reproducer (1.55 KB, text/x-csrc)
2013-12-06 14:06 UTC, Hubert Kario
no flags Details

Description Hubert Kario 2013-12-06 14:06:32 UTC
Created attachment 833619 [details]
reproducer

Description of problem:
When running reproducer for bug 772628, memory leaks are reported by valgrind

Version-Release number of selected component (if applicable):
nss-3.15.1-15.el6.x86_64

How reproducible:
Always, all architectures

Steps to Reproduce:
1. Compile attached source
2. Run under valgrind

Actual results:
==2044== 48 (8 direct, 40 indirect) bytes in 1 blocks are definitely lost in loss record 48 of 103
==2044==    at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298)
==2044==    by 0x68F4F79: ???
==2044==    by 0x50C1466: secmod_ModuleInit (pk11load.c:221)
==2044==    by 0x50C1DE6: secmod_LoadPKCS11Module (pk11load.c:457)
==2044==    by 0x50D56E9: SECMOD_LoadModule (pk11pars.c:1010)
==2044==    by 0x50D57DF: SECMOD_LoadModule (pk11pars.c:1045)
==2044==    by 0x50A4A93: nss_Init (nssinit.c:435)
==2044==    by 0x50A5260: NSS_InitContext (nssinit.c:834)
==2044==    by 0x3DA7C4044F: ??? (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C40602: Curl_nss_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C38481: Curl_ssl_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C16ECA: Curl_http_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044== 
==2044== 120 bytes in 1 blocks are definitely lost in loss record 58 of 103
==2044==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==2044==    by 0x6B18169: ???
==2044==    by 0x6903D0F: ???
==2044==    by 0x68F4E8C: ???
==2044==    by 0x50C1466: secmod_ModuleInit (pk11load.c:221)
==2044==    by 0x50C1DE6: secmod_LoadPKCS11Module (pk11load.c:457)
==2044==    by 0x50D56E9: SECMOD_LoadModule (pk11pars.c:1010)
==2044==    by 0x50D57DF: SECMOD_LoadModule (pk11pars.c:1045)
==2044==    by 0x50A4A93: nss_Init (nssinit.c:435)
==2044==    by 0x50A5260: NSS_InitContext (nssinit.c:834)
==2044==    by 0x3DA7C4044F: ??? (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C40602: Curl_nss_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044== 
==2044== 720 (120 direct, 600 indirect) bytes in 15 blocks are definitely lost in loss record 88 of 103
==2044==    at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298)
==2044==    by 0x6904F79: ???
==2044==    by 0x50C1466: secmod_ModuleInit (pk11load.c:221)
==2044==    by 0x50C1DE6: secmod_LoadPKCS11Module (pk11load.c:457)
==2044==    by 0x50D56E9: SECMOD_LoadModule (pk11pars.c:1010)
==2044==    by 0x50D57DF: SECMOD_LoadModule (pk11pars.c:1045)
==2044==    by 0x50A4A93: nss_Init (nssinit.c:435)
==2044==    by 0x50A5260: NSS_InitContext (nssinit.c:834)
==2044==    by 0x3DA7C4044F: ??? (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C40602: Curl_nss_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C38481: Curl_ssl_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C16ECA: Curl_http_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044== 
==2044== 1,800 bytes in 15 blocks are definitely lost in loss record 93 of 103
==2044==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==2044==    by 0x73CF169: ???
==2044==    by 0x6913D0F: ???
==2044==    by 0x6904E8C: ???
==2044==    by 0x50C1466: secmod_ModuleInit (pk11load.c:221)
==2044==    by 0x50C1DE6: secmod_LoadPKCS11Module (pk11load.c:457)
==2044==    by 0x50D56E9: SECMOD_LoadModule (pk11pars.c:1010)
==2044==    by 0x50D57DF: SECMOD_LoadModule (pk11pars.c:1045)
==2044==    by 0x50A4A93: nss_Init (nssinit.c:435)
==2044==    by 0x50A5260: NSS_InitContext (nssinit.c:834)
==2044==    by 0x3DA7C4044F: ??? (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C40602: Curl_nss_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044== 
==2044== LEAK SUMMARY:
==2044==    definitely lost: 2,048 bytes in 32 blocks
==2044==    indirectly lost: 640 bytes in 16 blocks
==2044==      possibly lost: 176 bytes in 4 blocks
==2044==    still reachable: 38,653 bytes in 119 blocks
==2044==         suppressed: 0 bytes in 0 blocks
==2044== Reachable blocks (those to which a pointer was found) are not shown.
==2044== To see them, rerun with: --leak-check=full --show-reachable=yes

Expected results:
No leakedm unreachable memory reported

Additional info:

Comment 1 Hubert Kario 2013-12-06 14:09:05 UTC
Small correction, the leaks are not present on s390x, they are present on x86_64, ppc64 and i386 architectures.


Note You need to log in before you can comment on or make changes to this bug.