JDK-6868466 : native memory leak in jdk6 (regression from jdk5)
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 6u14
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2009-08-04
  • Updated: 2010-09-29
  • Resolved: 2009-10-06
Related Reports
Duplicate :  
Relates :  
Description
Platform: T5200
OS: s10u5 + 137137-09

test matrix:

5u19: after 23M ops -> no error
6u14: after 5.6M ops -> java OOM

With 6u14, after 5.5 Millions socket connection
operations, the process size approached the 32bit process size
limit of 4G, and C heap usage is 3.9G. There is native memory leak
with 6u14, which causes the OOM.


Using libumem, I took samples of test run at around 37 thousands and
then at 110 thousands socket connection operations mark with 6u14 and 5u19.

Here are the findings:

C heap usage:

#ops    6u14 5u19
----------------------
37000:  106MB 33MB
110000: 217MB 33MB

libumem findleaks with 6u14: shows insignificant leak buffers

libumem umausers's top allocators:

37000/6u14:
>
> 4540160 bytes for 14188 allocations with data size 320:
> libumem.so.1`umem_cache_alloc+0x210
> libumem.so.1`umem_alloc+0x60
> libumem.so.1`malloc+0x28
> libumem.so.1`calloc+0x58
> libpkcs11.so.1`meta_object_alloc+8
> libpkcs11.so.1`meta_DeriveKey+0x260
> libpkcs11.so.1`C_DeriveKey+0xec
>
> libj2pkcs11.so`Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey+0x108
> 0xfc15e2a8
> 0xfc193914
> 0xfc19d18c
> 0xfc229038
> 0xfc1ac138
> 0xfc12cdac
> 0xfc15336c
> 4487040 bytes for 14022 allocations with data size 320:
> libumem.so.1`umem_cache_alloc+0x210
> libumem.so.1`umem_alloc+0x60
> libumem.so.1`malloc+0x28
> libumem.so.1`calloc+0x58
> libpkcs11.so.1`meta_object_alloc+8
> libpkcs11.so.1`meta_DeriveKey+0x260
> libpkcs11.so.1`C_DeriveKey+0xec
>
> libj2pkcs11.so`Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey+0x108
> 0xfc15e2a8
> 0xfc193914
> 0xfc19d18c
> 0xfc22913c
> 0xfc1ac138
> 0xfc12cdac
> 0xfc15336c
>
> <......more.....>
>
>
> 110000/6u14:
>
> 19248960 bytes for 60153 allocations with data size 320:
> libumem.so.1`umem_cache_alloc+0x210
> libumem.so.1`umem_alloc+0x60
> libumem.so.1`malloc+0x28
> libumem.so.1`calloc+0x58
> libpkcs11.so.1`meta_object_alloc+8
> libpkcs11.so.1`meta_DeriveKey+0x260
> libpkcs11.so.1`C_DeriveKey+0xec
>
> libj2pkcs11.so`Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey+0x108
> 0xfc15e2a8
> 0xfc193914
> 0xfc19d18c
> 0xfc229038
> 0xfc1ac138
> 0xfc12cdac
> 0xfc15336c
> 19033280 bytes for 59479 allocations with data size 320:
> libumem.so.1`umem_cache_alloc+0x210
> libumem.so.1`umem_alloc+0x60
> libumem.so.1`malloc+0x28
> libumem.so.1`calloc+0x58
> libpkcs11.so.1`meta_object_alloc+8
> libpkcs11.so.1`meta_DeriveKey+0x260
> libpkcs11.so.1`C_DeriveKey+0xec
>
> libj2pkcs11.so`Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey+0x108
> 0xfc15e2a8
> 0xfc193914
> 0xfc19d18c
> 0xfc22913c
> 0xfc1ac138
> 0xfc12cdac
> 0xfc15336c
>
> <....more...>
>

11100/5u19:

2606016 bytes for 1939 allocations with data size 1344:
libumem.so.1`umem_cache_alloc+0x210
libumem.so.1`umem_alloc+0x60
libumem.so.1`malloc+0x28
libpkcs11.so.1`get_master_attributes_by_type+0x34
libpkcs11.so.1`get_master_attributes_by_template+0xcc
libpkcs11.so.1`meta_CreateObject+0x398
libpkcs11.so.1`C_CreateObject+0xcc

libj2pkcs11.so`Java_sun_security_pkcs11_wrapper_PKCS11_C_1CreateObject+0x50
0xf8dc8a14
0xf8d5a9f4
0xf8d404e8
0xf8dc8fac
0xf8dc0f84
0xf8ccfd3c
0xf8daff80
715840 bytes for 2237 allocations with data size 320:
libumem.so.1`umem_cache_alloc+0x210
libumem.so.1`umem_alloc+0x60
libumem.so.1`malloc+0x28
libumem.so.1`calloc+0x58
libpkcs11.so.1`meta_object_alloc+8
libpkcs11.so.1`meta_CreateObject+0x64
libpkcs11.so.1`C_CreateObject+0xcc

libj2pkcs11.so`Java_sun_security_pkcs11_wrapper_PKCS11_C_1CreateObject+0x50
0xf8dc8a14
0xf8d5a9f4
0xf8d404e8
0xf8dc8fac
0xf8dc0f84
0xf8ccfd3c
0xf8daff80


The testcase is in the form of a jython script, which continuously open SSL 
connections to a webserver.

Here's the jython code:

i = 0
e = 0
while 1 :

  try :
    i += 1 ;
    sslsf = SSLSocketFactory.getDefault() ; ssls =
    sslsf.createSocket(str(sys.argv[1]),int(sys.argv[2])) ; ssls =
    ssls.session ; pcca = ssls.peerCertificateChain ; pcc = pcca[0] ;
    sdn = pcc.subjectDN ; if ( i % 1000 ) == 0 :
    print Date(),i,'sdn',sdn ;

  except Exception,java_exp :
    e += 1 ;
    exc_type, exc_value, exc_tb = sys.exc_info() print "Got Exception :
    "+str(exc_value) print "The (filename, line number, function,
    statement, value) is:"
    print str(traceback.extract_tb(exc_tb)) print 'java_exp',java_exp
    print 'java_exp',java_exp.printStackTrace()
    time.sleep(60) if e > 10000 :
    sys.exit()

Comments
EVALUATION After further experiment with the submitted test case, this cause of this bug appears to be the same as 6887619 instead of 4918870. The problem disappears when the CKM_TLS_PRF is disabled. Thus, I am closing this as a duplicate of 6887619.
06-10-2009

EVALUATION This is the incident that Mala reported with test case at /net/cores.central/cores/dir33/71010682/Jun16-data/test-case/lc/5220c which 4918870 seems to play a major factor according to the evaluation from Andrew. Thus, re-assigning this accordingly to Andrew so he can decide if this should be closed this as a duplicate of that.
15-09-2009