-
Bug
-
Resolution: Duplicate
-
P2
-
solaris_10, solaris_10u7, 6u14, 8
-
generic, sparc
-
solaris_10
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2186818 | 6-pool | Mala Bankal | P3 | Closed | Duplicate |
Based on the test results at hand, the memory usage remains flat when either:
1) the CKM_TLS_PRF mechanism is disabled, or
2) leave CKM_TLS_PRF mechanism enabled, but pass 0 as the base key in the C_DeriveKey(...) call instead of what actually specified by the caller. This leads to an error and Java crypto framework will fail over to the next crypto provider, i.e. SunJCE, for the TlsPrf algorithm.
Since everything else on java side is the same, it looks to be a Solaris crypto implementation issue. Please refer to 6750401 "SSL stress test with GF leads to 32 bit max process size in less than 5 minutes,with PCKS11 provider" for more details.
- backported by
-
JDK-2186818 Memory growth when using CKM_TLS_PRF mechanism with C_DeriveKey() calls
- Closed
- duplicates
-
JDK-6869672 Memory retention issues when using https handler
- Closed
-
JDK-6868466 native memory leak in jdk6 (regression from jdk5)
- Closed
-
JDK-2170532 SSL stress test with GF leads to 32 bit max process size in less than 5 minutes,with PCKS11 provider
- Closed
- relates to
-
JDK-6750401 SSL stress test with GF leads to 32 bit max process size in less than 5 minutes,with PCKS11 provider
- Closed
-
JDK-6913047 Long term memory leak when using PKCS11 and JCE exceeds 32 bit process address space
- Resolved