JDK-7177045 : [TEST_BUG] Rework the TestProviderLeak.java regression test, it is too fragile to low memory errors.
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-06-14
  • Updated: 2019-09-11
  • Resolved: 2012-08-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u85Fixed 8 b49Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
This test began failing when 7176176 was consuming too much memory during Java startup.

Comments
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1469be7182b4
14-08-2012

EVALUATION Changeset: 1469be7182b4 Author: khazra Date: 2012-07-16 16:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1469be7182b4 7177045: Rework the TestProviderLeak.java regression test, it is too fragile to low memory errors. Summary: Increase Xmx to 20 MB and add mechanisms to eat up most of the JVM free memory. Reviewed-by: wetmore Contributed-by: ###@###.### ! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java
16-07-2012

EVALUATION When testing the previous fix, I found the test ran for about 10 minutes to return the result in 64bit linux platform due to agressive GC activities, which is not acceptable. So I re-wrote the fix by adding time-out criteria. And the new test works as expected in 32bit & 64bit Linux, 32bit & 64bit Solaris, 64bit windows 7 and 32bit windows XP. I have sent the new test fix to Brad for code review.
25-06-2012

EVALUATION We were using a 2MB Java heap, and this was too small as the JDK grew. Instead of making an arbitrarily short heap, we will simply use a 200MB heap, and continuously allocate 1MB byte buffers until we run out of memory. Then we'll release some of them, have the GC free, then we will run the existing test. *** (#1 of 1): [ UNSAVED ] ###@###.###
14-06-2012