Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6868466

native memory leak in jdk6 (regression from jdk5)

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: P3 P3
    • None
    • 6u14
    • security-libs
    • None

      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()

            xuelei Xuelei Fan
            lkchow Lawrence Chow
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: