JDK-8027624 : [TEST_BUG] com/sun/crypto/provider/KeyFactory/TestProviderLeak.java unstable again
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-10-31
  • Updated: 2015-05-11
  • Resolved: 2013-11-01
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 Other
7u85Fixed 8 b117Fixed port-stage-ppc-aixFixed
Related Reports
Relates :  
JDK-7177045 - [TEST_BUG] Rework the TestProviderLeak.java regression test, it is too fragile to low memory errors.
Relates :  
JDK-7176176 - Need to make improvement to access temporary dir
Relates :  
JDK-8044763 - com/sun/crypto/provider/KeyFactory/TestProviderLeak.java failed in JDK9
Description
This test seems to have become unstable again. Here's an example on Linux x64 (no jtreg, just running the test directly with an up-to-date build of jdk8/tl):

$ java -Xmx20m TestProviderLeak
Before memory allocation:	20020296 bytes free
OOME is thrown when allocating 17MB memory.
After memory allocation:	5511744 bytes free
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
	at java.lang.StringCoding$StringDecoder.decode(StringCoding.java:149)
	at java.lang.StringCoding.decode(StringCoding.java:193)
	at java.lang.String.<init>(String.java:419)
	at java.lang.String.<init>(String.java:484)
	at java.io.UnixFileSystem.list(Native Method)
	at java.io.File.list(File.java:1122)
	at javax.crypto.JarVerifier.getSystemEntropy(JarVerifier.java:785)
	at javax.crypto.JarVerifier.testSignatures(JarVerifier.java:706)
	at javax.crypto.JarVerifier.access$400(JarVerifier.java:34)
	at javax.crypto.JarVerifier$1.run(JarVerifier.java:183)
	at javax.crypto.JarVerifier$1.run(JarVerifier.java:149)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.crypto.JarVerifier.<clinit>(JarVerifier.java:148)
	at javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:316)
	at javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:261)
	at javax.crypto.JceSecurity.access$000(JceSecurity.java:48)
	at javax.crypto.JceSecurity$1.run(JceSecurity.java:81)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:78)
	at javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:204)
	at TestProviderLeak.main(TestProviderLeak.java:98)
Comments
Verified based on the nightly aurora results. No failures of test com/sun/crypto/provider/KeyFactory/TestProviderLeak.java seen in the last 15 days
05-12-2013
Yes, I'd say too late, given everything left to do/investigate. When we finally get to JDK-7176176, we'll look at that change.
01-11-2013
I checked the system where this test has been failing a lot recently and there are huge number of files in /tmp (left over by other tests). Having the File.list usage to use DirectoryStream would certainly reduce the memory usage (but that is an implementation change and it might be too late in JDK 8 to do that).
01-11-2013
This test is failing during Jar file verification *following* the eating of memory. Maybe the SecretKeyFactory.getInstance("...") should be done before eatupMemory()?
31-10-2013
Assigned to previous owner of JDK-7177045. If he isn't able to analyze, he can unassign. Probably just need to bump the -Xmx20m limit.
31-10-2013