hg: jdk8/tl/jdk: 8028505: Put sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh on ProblemList.txt
Changeset: d6195774dd1f Author:egahlin Date: 2013-11-19 11:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6195774dd1f 8028505: Put sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh on ProblemList.txt Reviewed-by: alanb ! test/ProblemList.txt
hg: jdk8/tl/jdk: 7086879: java/net/InetAddress/CheckJNI.java hangs on Linux when IPv6 enabled
Changeset: d5ddde25d107 Author:tyan Date: 2013-11-19 13:46 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5ddde25d107 7086879: java/net/InetAddress/CheckJNI.java hangs on Linux when IPv6 enabled Reviewed-by: chegar ! test/ProblemList.txt
hg: jdk8/tl/jdk: 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests
Changeset: 2e574350a2b6 Author:alanb Date: 2013-11-19 14:08 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2e574350a2b6 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests Reviewed-by: dholmes, sla, tbell ! test/Makefile
hg: jdk8/tl: 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests
Changeset: 9937f406e27e Author:alanb Date: 2013-11-19 14:11 + URL: http://hg.openjdk.java.net/jdk8/tl/rev/9937f406e27e 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests Reviewed-by: dholmes, sla, tbell ! make/jprt.properties ! test/Makefile
[8] RFR 8028377: test/sun/security/provider/KeyStore/DKSTest.sh attempts to write to ${test.src}
Please review the following test fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8028377 Webrev: http://cr.openjdk.java.net/~vinnie/8028377/webrev.00/ It now writes temporary keystores in the test scratch area (not the test source area). Thanks.
Re: [8] RFR 8028377: test/sun/security/provider/KeyStore/DKSTest.sh attempts to write to ${test.src}
On 19/11/2013 14:16, Vincent Ryan wrote: Please review the following test fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8028377 Webrev: http://cr.openjdk.java.net/~vinnie/8028377/webrev.00/ It now writes temporary keystores in the test scratch area (not the test source area). This looks okay to me. One suggestion is to use the two-arg File constructor rather than String concatenation. -Alan.
Re: [8] RFR 8028377: test/sun/security/provider/KeyStore/DKSTest.sh attempts to write to ${test.src}
Why not just put the file in the current directory? That's the real scratch dir. Or the cfg file needs an absolute path? Also, is it necessary to remove the files in finally? If the test fails, the files will be retained by jtreg so we can look into the reason. Or, these lines are added to make sure the files are removable? But then I think File::delete will not fail if a file is not removable. Files::delete is better. Thanks Max On 11/19/13, 22:16, Vincent Ryan wrote: Please review the following test fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8028377 Webrev: http://cr.openjdk.java.net/~vinnie/8028377/webrev.00/ It now writes temporary keystores in the test scratch area (not the test source area). Thanks.
Re: [8] RFR 8028377: test/sun/security/provider/KeyStore/DKSTest.sh attempts to write to ${test.src}
Thanks Alan. I've changed to using the two-arg constructor for File and I've updated the webrev in place. On 19/11/2013 14:23, Alan Bateman wrote: On 19/11/2013 14:16, Vincent Ryan wrote: Please review the following test fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8028377 Webrev: http://cr.openjdk.java.net/~vinnie/8028377/webrev.00/ It now writes temporary keystores in the test scratch area (not the test source area). This looks okay to me. One suggestion is to use the two-arg File constructor rather than String concatenation. -Alan.
hg: jdk8/tl/jdk: 8028583: Add helper methods to test libraries
Changeset: d1bb85f0a45a Author:coffeys Date: 2013-11-19 14:47 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1bb85f0a45a 8028583: Add helper methods to test libraries Reviewed-by: chegar ! test/java/rmi/testlibrary/TestLibrary.java ! test/lib/testlibrary/jdk/testlibrary/FileUtils.java
hg: jdk8/tl/jdk: 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm
Changeset: 40462a41b41b Author:ksrini Date: 2013-11-19 07:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40462a41b41b 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm Reviewed-by: dholmes, mchung ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java
Re: [8] RFR 8028377: test/sun/security/provider/KeyStore/DKSTest.sh attempts to write to ${test.src}
On 19/11/2013 14:30, Weijun Wang wrote:
Why not just put the file in the current directory? That's the real
scratch dir. Or the cfg file needs an absolute path?
Good point Max. The cfg file does require an absolute path so I've
changed the test to now write to {user.dir}.
And I've updated the webrev (in place).
Also, is it necessary to remove the files in finally? If the test fails,
the files will be retained by jtreg so we can look into the reason. Or,
these lines are added to make sure the files are removable? But then I
think File::delete will not fail if a file is not removable.
Files::delete is better.
I previously encountered a problem when tests were running concurrently
but now that I write to {user.dir} I can remove that finally block.
Thanks
Max
On 11/19/13, 22:16, Vincent Ryan wrote:
Please review the following test fix:
Bug: https://bugs.openjdk.java.net/browse/JDK-8028377
Webrev: http://cr.openjdk.java.net/~vinnie/8028377/webrev.00/
It now writes temporary keystores in the test scratch area
(not the test source area).
Thanks.
hg: jdk8/tl/jdk: 8028094: TEST_BUG: java/lang/ProcessBuilder/Basic.java leaves sleep 6666 processes behind
Changeset: cfbee8ee71bf Author:bvaidya Date: 2013-11-19 15:31 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cfbee8ee71bf 8028094: TEST_BUG: java/lang/ProcessBuilder/Basic.java leaves sleep processes behind Reviewed-by: chegar ! test/java/lang/ProcessBuilder/Basic.java
hg: jdk8/tl/jdk: 2 new changesets
Changeset: e8daf5a83e42
Author:vinnie
Date: 2013-11-19 15:39 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8daf5a83e42
8028377: test/sun/security/provider/KeyStore/DKSTest.sh attempts to write to
${test.src}
Reviewed-by: alanb, weijun
! test/sun/security/provider/KeyStore/DKSTest.java
! test/sun/security/provider/KeyStore/domains.cfg
Changeset: bfd4e632eeda
Author:vinnie
Date: 2013-11-19 15:42 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bfd4e632eeda
Merge
hg: jdk8/tl/jdk: 8028581: [TESTBUG] java/net/Socket/LingerTest.java failing
Changeset: 79e975dfeb8a Author:michaelm Date: 2013-11-19 17:49 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79e975dfeb8a 8028581: [TESTBUG] java/net/Socket/LingerTest.java failing Reviewed-by: alanb ! test/java/net/Socket/LingerTest.java
hg: jdk8/tl/jdk: 8027900: pack200 option is broken due to the incorrect makefile definition for its driver
Changeset: 5aa853ca08a8 Author:kizune Date: 2013-11-19 22:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5aa853ca08a8 8027900: pack200 option is broken due to the incorrect makefile definition for its driver Reviewed-by: ksrini, ihse ! make/CompileLaunchers.gmk
hg: jdk8/tl/jdk: 8015571: OCSP validation fails if ocsp.responderCertSubjectName is set
Changeset: f8b24e1a609e Author:vinnie Date: 2013-11-19 17:55 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8b24e1a609e 8015571: OCSP validation fails if ocsp.responderCertSubjectName is set Reviewed-by: mullan, xuelei ! src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/OCSPRequest.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/x509/X509CertImpl.java
hg: jdk8/tl/jdk: 8028565: Remove java/lang/management/ThreadMXBean/ThreadStateTest.java from ProblemList.txt
Changeset: 48c61808374f Author:mchung Date: 2013-11-19 10:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48c61808374f 8028565: Remove java/lang/management/ThreadMXBean/ThreadStateTest.java from ProblemList.txt Reviewed-by: sla ! test/ProblemList.txt
hg: jdk8/tl/jdk: 8028141: test/sun/management/jmxremote/bootstrap/LocalManagementTest|CustomLauncherTest.java failing again
Changeset: 3f47e393e1dd Author:rriggs Date: 2013-11-19 13:20 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f47e393e1dd 8028141: test/sun/management/jmxremote/bootstrap/LocalManagementTest|CustomLauncherTest.java failing again Summary: Correct to use the test.class.path instead of test.classes Reviewed-by: alanb, chegar ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java
hg: jdk8/tl/jdk: 8028185: XMLFormatter.format emits incorrect year
Changeset: 67d742c75971 Author:dfuchs Date: 2013-11-19 20:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/67d742c75971 8028185: XMLFormatter.format emits incorrect year Summary: Fixes a regression where the year in the date was increased by 1900. Reviewed-by: alanb, mchung ! src/share/classes/java/util/logging/XMLFormatter.java + test/java/util/logging/XMLFormatterDate.java
hg: jdk8/tl/jdk: 8005202: java/util/logging/CheckLockLocationTest.java fail on solars_10
Changeset: 059530c5ae9a Author:dfuchs Date: 2013-11-19 22:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/059530c5ae9a 8005202: java/util/logging/CheckLockLocationTest.java fail on solars_10 Summary: this test has been seen failing on Solaris 10, presumably because it was run as root. The fix will skip the non-writable case if it can't make a non-writable dir. Reviewed-by: mchung ! test/java/util/logging/CheckLockLocationTest.java
hg: jdk8/tl/jdk: 8028631: Improve the test coverage to the pathname handling on unix-like platforms
Changeset: f496565c4eec Author:dxu Date: 2013-11-19 13:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f496565c4eec 8028631: Improve the test coverage to the pathname handling on unix-like platforms Summary: Add GeneralSolaris.java testcase and fix the concurrency issue Reviewed-by: lancea, chegar, alanb ! test/java/io/pathNames/General.java + test/java/io/pathNames/GeneralSolaris.java ! test/java/io/pathNames/GeneralWin32.java
Re: [8] RFR 8028377: test/sun/security/provider/KeyStore/DKSTest.sh attempts to write to ${test.src}
If the test passed, these temporary files should be removed, shouldn't they?
Thanks,
Valerie
On 11/19/13 07:29, Vincent Ryan wrote:
On 19/11/2013 14:30, Weijun Wang wrote:
Why not just put the file in the current directory? That's the real
scratch dir. Or the cfg file needs an absolute path?
Good point Max. The cfg file does require an absolute path so I've
changed the test to now write to {user.dir}.
And I've updated the webrev (in place).
Also, is it necessary to remove the files in finally? If the test fails,
the files will be retained by jtreg so we can look into the reason. Or,
these lines are added to make sure the files are removable? But then I
think File::delete will not fail if a file is not removable.
Files::delete is better.
I previously encountered a problem when tests were running concurrently
but now that I write to {user.dir} I can remove that finally block.
Thanks
Max
On 11/19/13, 22:16, Vincent Ryan wrote:
Please review the following test fix:
Bug: https://bugs.openjdk.java.net/browse/JDK-8028377
Webrev: http://cr.openjdk.java.net/~vinnie/8028377/webrev.00/
It now writes temporary keystores in the test scratch area
(not the test source area).
Thanks.
Re: [8] RFR 8028377: test/sun/security/provider/KeyStore/DKSTest.sh attempts to write to ${test.src}
Hello Valerie,
They get written to the scratch directory for the testrun so I
don't think it is necessary to delete them explicitly.
I'll confirm that.
Thanks.
On 19/11/2013 21:58, Valerie (Yu-Ching) Peng wrote:
If the test passed, these temporary files should be removed, shouldn't
they?
Thanks,
Valerie
On 11/19/13 07:29, Vincent Ryan wrote:
On 19/11/2013 14:30, Weijun Wang wrote:
Why not just put the file in the current directory? That's the real
scratch dir. Or the cfg file needs an absolute path?
Good point Max. The cfg file does require an absolute path so I've
changed the test to now write to {user.dir}.
And I've updated the webrev (in place).
Also, is it necessary to remove the files in finally? If the test fails,
the files will be retained by jtreg so we can look into the reason. Or,
these lines are added to make sure the files are removable? But then I
think File::delete will not fail if a file is not removable.
Files::delete is better.
I previously encountered a problem when tests were running concurrently
but now that I write to {user.dir} I can remove that finally block.
Thanks
Max
On 11/19/13, 22:16, Vincent Ryan wrote:
Please review the following test fix:
Bug: https://bugs.openjdk.java.net/browse/JDK-8028377
Webrev: http://cr.openjdk.java.net/~vinnie/8028377/webrev.00/
It now writes temporary keystores in the test scratch area
(not the test source area).
Thanks.
hg: jdk8/tl/jdk: 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails
Changeset: 19d2e9649138 Author:smarks Date: 2013-11-19 15:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19d2e9649138 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails Reviewed-by: lancea ! test/java/rmi/testlibrary/RMID.java
hg: jdk8/tl/langtools: 8028504: javac generates LocalVariableTable even with -g:none
Changeset: 66bcd5d4b3d1 Author:vromero Date: 2013-11-19 23:35 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/66bcd5d4b3d1 8028504: javac generates LocalVariableTable even with -g:none Reviewed-by: jjg, jlahoda ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/tools/javac/T8028504/DontGenerateLVTForGNoneOpTest.java
Thoughts on possible options to JDK-8027598
I am working towards fixing JDK-8027598 https://bugs.openjdk.java.net/browse/JDK-8027598, there are multiple options available here and would appreciate your thoughts on this. It was filed to address the issue at large reported inJDK-8027526 https://bugs.openjdk.java.net/browse/JDK-8027526. Problem - When a regression test is run in agentvm mode and alters security providers, it can cause adverse effects on next tests executed in the batch. We have been batteling with few intermittent failures which are caused by scenario like this so I think it is important to have this fix. Possible approaches - 1. Enhance JTREG - This option would require change in jtreg to store/restore security providers when run in agentvm mode. 2. Update impacting tests to run in othervm - simple change but may slow down batch execution slightly. 3. Update each test to use library java/security/KeyPairGenerator/Failover.java like done in java/security/Provider tests - another easy change and tests would continue to run agentvm but would have added overhead of restoring providers. We will continue to pursue option 1 but many not be possible. Option 2 3 above are equally good and are debatable so would like your thoughts on it. Thanks, Rajan
Re: Thoughts on possible options to JDK-8027598
On 11/20/2013 8:19 AM, Rajan Halade wrote: I am working towards fixing JDK-8027598 https://bugs.openjdk.java.net/browse/JDK-8027598, there are multiple options available here and would appreciate your thoughts on this. It was filed to address the issue at large reported inJDK-8027526 https://bugs.openjdk.java.net/browse/JDK-8027526. Problem - When a regression test is run in agentvm mode and alters security providers, it can cause adverse effects on next tests executed in the batch. We have been batteling with few intermittent failures which are caused by scenario like this so I think it is important to have this fix. Possible approaches - 1. Enhance JTREG - This option would require change in jtreg to store/restore security providers when run in agentvm mode. If I am correct, JTREG has support provider cleanup already. But the question is even JTREG reset the providers, it still cannot ensure next test won't be impacted because in some circumstances JDK may need to cache something which depends on previous providers. Still need to analysis the test case by case. Xuelei 2. Update impacting tests to run in othervm - simple change but may slow down batch execution slightly. 3. Update each test to use library java/security/KeyPairGenerator/Failover.java like done in java/security/Provider tests - another easy change and tests would continue to run agentvm but would have added overhead of restoring providers. We will continue to pursue option 1 but many not be possible. Option 2 3 above are equally good and are debatable so would like your thoughts on it. Thanks, Rajan
Code Review Request for 7200306: SunPKCS11 provider delays the check of DSA key size for SHA1withDSA to sign() instead of init()
Can someone please help review my fixes for 7200306: SunPKCS11 provider delays the check of DSA key size for SHA1withDSA to sign() instead of init()? Native PKCS11 libraries don't seem to check the key during the initialization calls (triggered by initSign()/initVerify()). Rather, it errors out during the subsequent update() calls. So, I added necessary key length checks. Webrev: http://cr.openjdk.java.net/~valeriep/7200306/webrev.00/ Thanks, Valerie
Re: Thoughts on possible options to JDK-8027598
On 11/19/2013 4:19 PM, Rajan Halade wrote: I am working towards fixing JDK-8027598 https://bugs.openjdk.java.net/browse/JDK-8027598, there are multiple options available here and would appreciate your thoughts on this. It was filed to address the issue at large reported inJDK-8027526 https://bugs.openjdk.java.net/browse/JDK-8027526. Problem - When a regression test is run in agentvm mode and alters security providers, it can cause adverse effects on next tests executed in the batch. We have been batteling with few intermittent failures which are caused by scenario like this so I think it is important to have this fix. Possible approaches - 1. Enhance JTREG - This option would require change in jtreg to store/restore security providers when run in agentvm mode. That is my preference. I'm also cc'ing Jonathan Gibbons who should also be involved. I believe you can just look to see if the provider list has been updated, then restore only if that is the case. 2. Update impacting tests to run in othervm - simple change but may slow down batch execution slightly. Correct. I am not suggesting the following, but one other thing that was proposed was to update the Makefiles to run the java_security* targets in othervm, but that doesn't work when calling jtreg directly, and impacts all tests in that target. 3. Update each test to use library java/security/KeyPairGenerator/Failover.java like done in java/security/Provider tests - another easy change and tests would continue to run agentvm but would have added overhead of restoring providers. We will continue to pursue option 1 but many not be possible. Option 2 3 above are equally good and are debatable so would like your thoughts on it. I would suggest pursing in order 1, 3, 2. Brad Thanks, Rajan
Re: Thoughts on possible options to JDK-8027598
On 11/19/2013 5:07 PM, Xuelei Fan wrote: On 11/20/2013 8:19 AM, Rajan Halade wrote: I am working towards fixing JDK-8027598 https://bugs.openjdk.java.net/browse/JDK-8027598, there are multiple options available here and would appreciate your thoughts on this. It was filed to address the issue at large reported inJDK-8027526 https://bugs.openjdk.java.net/browse/JDK-8027526. Problem - When a regression test is run in agentvm mode and alters security providers, it can cause adverse effects on next tests executed in the batch. We have been batteling with few intermittent failures which are caused by scenario like this so I think it is important to have this fix. Possible approaches - 1. Enhance JTREG - This option would require change in jtreg to store/restore security providers when run in agentvm mode. If I am correct, JTREG has support provider cleanup already. No, it does not currently. Brad But the question is even JTREG reset the providers, it still cannot ensure next test won't be impacted because in some circumstances JDK may need to cache something which depends on previous providers. Still need to analysis the test case by case. Xuelei 2. Update impacting tests to run in othervm - simple change but may slow down batch execution slightly. 3. Update each test to use library java/security/KeyPairGenerator/Failover.java like done in java/security/Provider tests - another easy change and tests would continue to run agentvm but would have added overhead of restoring providers. We will continue to pursue option 1 but many not be possible. Option 2 3 above are equally good and are debatable so would like your thoughts on it. Thanks, Rajan
