Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

[Xuelei Fan]

On 9/15/2016 9:45 AM, Artem Smotrakov wrote:

Well, in this particular case it's not clear that it has the same issue
with free port (at least to me). The exception occurred on client side,
so it's not the case where we don't know where the handshake came from.

;-) Yeh, you catch the point.  But there is a free-port issue although 
the exception stack in the bug description may be not that case.


Let's look at a scenarios:
1. server open a server socket and listen.
2. other test case connect to the server socket.
3. this test case try to connect to server socket.
4. this test case would fail as the server only accept one connections.

I did not check it very carefully, I think for #4, the exception stack 
can be similar to the one in the bug description.


Anyway, as a free port is used, there are free-port issues.  Please 
consider to make the enhancement in the fix.  Otherwise, you cannot 
avoid the intermittent failure for this test case in the current testing 
environment.


Xuelei


I can make this enhancement, but like I said I don't think it's going to
help, so I would like to keep debug output on.

Artem


On 09/14/2016 06:39 PM, Xuelei Fan wrote:

On 9/15/2016 9:23 AM, Artem Smotrakov wrote:

Hi Xuelei,

For this one, I am not sure that it would help here since the test
failed after it already had started handshaking.

It has the same issue as a free-port is used.  We don't actually know
the handshake is coming from the right client.

Xuelei


I would prefer to have it as a separate enhancement.

Artem


On 09/14/2016 06:19 PM, Xuelei Fan wrote:

As you were already there, I would suggest to consider the
SSLSocketSample.java template as the comment in JDK-8163924 review
thread.

Thanks,
Xuelei

On 9/15/2016 9:13 AM, Artem Smotrakov wrote:

Not urgent, but I would appreciate if someone can get a chance to look
at this.

Artem


On 09/07/2016 03:17 PM, Artem Smotrakov wrote:

Sending to net-...@openjdk.java.net as well.

Artem


On 09/07/2016 12:28 PM, Artem Smotrakov wrote:

Hello,

Please review the following patch for
sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java

The test has been observed to fail a couple of times, but it's still
not clear why it failed because there is not much info in logs. The
patch updates the test to enable additional debug output, so that we
have more info if it fails next time.

While looking at the test, I notices a couple of issues, but they
don't seem to cause these intermittent failures:
- The test sets system properties for JSSE in a loop, but JSSE
provider reads them only once while initialization. As a result,
only
values which were set in the first iteration are actually used.
- The test doesn't close files and sockets sometimes.

The patch also fixed the issues above, and there are a couple
cosmetic changes.

Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/

Artem

Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

[Artem Smotrakov]

Well, in this particular case it's not clear that it has the same issue 
with free port (at least to me). The exception occurred on client side, 
so it's not the case where we don't know where the handshake came from.


I can make this enhancement, but like I said I don't think it's going to 
help, so I would like to keep debug output on.


Artem


On 09/14/2016 06:39 PM, Xuelei Fan wrote:

On 9/15/2016 9:23 AM, Artem Smotrakov wrote:

Hi Xuelei,

For this one, I am not sure that it would help here since the test
failed after it already had started handshaking.
It has the same issue as a free-port is used.  We don't actually know 
the handshake is coming from the right client.


Xuelei


I would prefer to have it as a separate enhancement.

Artem


On 09/14/2016 06:19 PM, Xuelei Fan wrote:

As you were already there, I would suggest to consider the
SSLSocketSample.java template as the comment in JDK-8163924 review
thread.

Thanks,
Xuelei

On 9/15/2016 9:13 AM, Artem Smotrakov wrote:

Not urgent, but I would appreciate if someone can get a chance to look
at this.

Artem


On 09/07/2016 03:17 PM, Artem Smotrakov wrote:

Sending to net-...@openjdk.java.net as well.

Artem


On 09/07/2016 12:28 PM, Artem Smotrakov wrote:

Hello,

Please review the following patch for
sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java

The test has been observed to fail a couple of times, but it's still
not clear why it failed because there is not much info in logs. The
patch updates the test to enable additional debug output, so that we
have more info if it fails next time.

While looking at the test, I notices a couple of issues, but they
don't seem to cause these intermittent failures:
- The test sets system properties for JSSE in a loop, but JSSE
provider reads them only once while initialization. As a result, 
only

values which were set in the first iteration are actually used.
- The test doesn't close files and sockets sometimes.

The patch also fixed the issues above, and there are a couple
cosmetic changes.

Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/

Artem

Re: RFR(M): 8166032: Fix module dependencies for javax.SSL tests

[Xuelei Fan]

On 9/15/2016 9:36 AM, Wang Weijun wrote:

I see. But krb5 cipher suites is just a very small part of TLS. Maybe we can 
tweak the tests a little so that they can work without JGSS.

Agreed.  I don't like the dependence, too.  Let's consider an 
enhancement later in a separate enhancement.


Xuelei


I am fine with the change at the moment.

Thanks
Max


On Sep 15, 2016, at 7:39 AM, Xuelei Fan  wrote:

I did some research yesterday.  The "/javax/net/ssl/TLSCommon" lib depends on 
krb5.  For example, BufferOverflowUnderflowTest need to set up KDC and test krb5 cipher 
suites.

Xuelei

On 9/15/2016 6:21 AM, Wang Weijun wrote:

Confusing. This does not show why jgss is needed. I'll do some
investigation.

Thanks
Max

在 2016年9月14日，23:57，Sergei Kovalev > 写道：


java.lang.module.ResolutionException: Module java.naming not found,
required by java.security.jgss

Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

[Xuelei Fan]

On 9/15/2016 9:23 AM, Artem Smotrakov wrote:

Hi Xuelei,

For this one, I am not sure that it would help here since the test
failed after it already had started handshaking.
It has the same issue as a free-port is used.  We don't actually know 
the handshake is coming from the right client.


Xuelei


I would prefer to have it as a separate enhancement.

Artem


On 09/14/2016 06:19 PM, Xuelei Fan wrote:

As you were already there, I would suggest to consider the
SSLSocketSample.java template as the comment in JDK-8163924 review
thread.

Thanks,
Xuelei

On 9/15/2016 9:13 AM, Artem Smotrakov wrote:

Not urgent, but I would appreciate if someone can get a chance to look
at this.

Artem


On 09/07/2016 03:17 PM, Artem Smotrakov wrote:

Sending to net-...@openjdk.java.net as well.

Artem


On 09/07/2016 12:28 PM, Artem Smotrakov wrote:

Hello,

Please review the following patch for
sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java

The test has been observed to fail a couple of times, but it's still
not clear why it failed because there is not much info in logs. The
patch updates the test to enable additional debug output, so that we
have more info if it fails next time.

While looking at the test, I notices a couple of issues, but they
don't seem to cause these intermittent failures:
- The test sets system properties for JSSE in a loop, but JSSE
provider reads them only once while initialization. As a result, only
values which were set in the first iteration are actually used.
- The test doesn't close files and sockets sometimes.

The patch also fixed the issues above, and there are a couple
cosmetic changes.

Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/

Artem

Re: RFR(M): 8166032: Fix module dependencies for javax.SSL tests

[Wang Weijun]

I see. But krb5 cipher suites is just a very small part of TLS. Maybe we can 
tweak the tests a little so that they can work without JGSS.

I am fine with the change at the moment.

Thanks
Max

> On Sep 15, 2016, at 7:39 AM, Xuelei Fan  wrote:
> 
> I did some research yesterday.  The "/javax/net/ssl/TLSCommon" lib depends on 
> krb5.  For example, BufferOverflowUnderflowTest need to set up KDC and test 
> krb5 cipher suites.
> 
> Xuelei
> 
> On 9/15/2016 6:21 AM, Wang Weijun wrote:
>> Confusing. This does not show why jgss is needed. I'll do some
>> investigation.
>> 
>> Thanks
>> Max
>> 
>> 在 2016年9月14日，23:57，Sergei Kovalev > > 写道：
>> 
>>> java.lang.module.ResolutionException: Module java.naming not found,
>>> required by java.security.jgss

Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

[Artem Smotrakov]

Hi Xuelei,

For this one, I am not sure that it would help here since the test 
failed after it already had started handshaking. I would prefer to have 
it as a separate enhancement.


Artem


On 09/14/2016 06:19 PM, Xuelei Fan wrote:
As you were already there, I would suggest to consider the 
SSLSocketSample.java template as the comment in JDK-8163924 review 
thread.


Thanks,
Xuelei

On 9/15/2016 9:13 AM, Artem Smotrakov wrote:

Not urgent, but I would appreciate if someone can get a chance to look
at this.

Artem


On 09/07/2016 03:17 PM, Artem Smotrakov wrote:

Sending to net-...@openjdk.java.net as well.

Artem


On 09/07/2016 12:28 PM, Artem Smotrakov wrote:

Hello,

Please review the following patch for
sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java

The test has been observed to fail a couple of times, but it's still
not clear why it failed because there is not much info in logs. The
patch updates the test to enable additional debug output, so that we
have more info if it fails next time.

While looking at the test, I notices a couple of issues, but they
don't seem to cause these intermittent failures:
- The test sets system properties for JSSE in a loop, but JSSE
provider reads them only once while initialization. As a result, only
values which were set in the first iteration are actually used.
- The test doesn't close files and sockets sometimes.

The patch also fixed the issues above, and there are a couple
cosmetic changes.

Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/

Artem

Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

[Xuelei Fan]

As you were already there, I would suggest to consider the 
SSLSocketSample.java template as the comment in JDK-8163924 review thread.


Thanks,
Xuelei

On 9/15/2016 9:13 AM, Artem Smotrakov wrote:

Not urgent, but I would appreciate if someone can get a chance to look
at this.

Artem


On 09/07/2016 03:17 PM, Artem Smotrakov wrote:

Sending to net-...@openjdk.java.net as well.

Artem


On 09/07/2016 12:28 PM, Artem Smotrakov wrote:

Hello,

Please review the following patch for
sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java

The test has been observed to fail a couple of times, but it's still
not clear why it failed because there is not much info in logs. The
patch updates the test to enable additional debug output, so that we
have more info if it fails next time.

While looking at the test, I notices a couple of issues, but they
don't seem to cause these intermittent failures:
- The test sets system properties for JSSE in a loop, but JSSE
provider reads them only once while initialization. As a result, only
values which were set in the first iteration are actually used.
- The test doesn't close files and sockets sometimes.

The patch also fixed the issues above, and there are a couple
cosmetic changes.

Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/

Artem

Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

[Artem Smotrakov]

Not urgent, but I would appreciate if someone can get a chance to look 
at this.


Artem


On 09/07/2016 03:17 PM, Artem Smotrakov wrote:

Sending to net-...@openjdk.java.net as well.

Artem


On 09/07/2016 12:28 PM, Artem Smotrakov wrote:

Hello,

Please review the following patch for 
sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java


The test has been observed to fail a couple of times, but it's still 
not clear why it failed because there is not much info in logs. The 
patch updates the test to enable additional debug output, so that we 
have more info if it fails next time.


While looking at the test, I notices a couple of issues, but they 
don't seem to cause these intermittent failures:
- The test sets system properties for JSSE in a loop, but JSSE 
provider reads them only once while initialization. As a result, only 
values which were set in the first iteration are actually used.

- The test doesn't close files and sockets sometimes.

The patch also fixed the issues above, and there are a couple 
cosmetic changes.


Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/

Artem

Re: [9] RFR: 8163924: SSLEngineBadBufferArrayAccess.java fails intermittently with Unrecognized SSL message

[Artem Smotrakov]

Hi Xuelei,

Sure, I am fine to use the approach which is implemented in 
SSLSocketSample.java. But please note that 
SSLEngineBadBufferArrayAccess.java test uses ServerSocket+SSEngine on 
server side, so I applied the approach from SSLSocketSample.java to the 
test:


http://cr.openjdk.java.net/~asmotrak/8163924/webrev.01/

If everything is okay, I am going to apply this approach to other test 
bugs we have.


I am wondering if we could move some common code from 
SSLSocketSample.java to a helper class, so that it could be re-used by 
other tests (not for all of them because tests may be different). It 
might reduce some duplicate code.


Artem


On 09/13/2016 06:39 PM, Xuelei Fan wrote:
I think the failure may caused by using free port by other test cases. 
As you were already there, would you mind update to use the 
SSLSocketSample.java template under the folder 
test/javax/net/ssl/templates?


Thanks,
Xuelei

On 9/14/2016 9:31 AM, Artem Smotrakov wrote:

Hello,

Not urgent, but I would appreciate if somebody can take a look at the
webrev below and webvev for 8164591. Thank you!

Artem

On 09/07/2016 02:58 PM, Artem Smotrakov wrote:

Hello,

Please review the following patch for
SSLEngineBadBufferArrayAccess.java test.

The test has been observed to fail intermittently with "Unrecognized
SSL message" error. I couldn't reproduce it, and it's currently not
clear what caused the test to fail. One guess is that something else
might connect to the server which caused this error. The patch enables
additional debug output, so that we have more info if it fails next
time. JTREG truncates logs, but it's fine since we are interested only
in last handshaking.

The patch also updates the test to report unexpected exceptions, and
close files and sockets.

Any other suggestions are very welcome.

Bug: https://bugs.openjdk.java.net/browse/JDK-8163924
Webrev: http://cr.openjdk.java.net/~asmotrak/8163924/webrev.00/

Artem

Code Review Request, JDK-8146600 AVA Normalizer.Form issue

[Xuelei Fan]

Hi,

Please review this fix:
http://cr.openjdk.java.net/~xuelei/8146600/webrev.00/

The Normalizer.Form.NFKD is used to normalize attribute-value assertion 
in X.509 certificate processing.  The normalizer may convert some UTF-8 
character into ASCII code.  For example, "，"(two bytes) will be 
converted to ","(one byte), and "Hello， world!" is normalize to "Hello, 
world!".  However, "Hello, world!" and "Hello， world!" should be 
different because of the comma code.  This conversion may result in 
unexpected weird behaviors for name comparing and conversions.


This fix will update to use "Normalizer.Form.NFD".

Thanks,
Xuelei

Re: RFR(M): 8166032: Fix module dependencies for javax.SSL tests

[Xuelei Fan]

I did some research yesterday.  The "/javax/net/ssl/TLSCommon" lib 
depends on krb5.  For example, BufferOverflowUnderflowTest need to set 
up KDC and test krb5 cipher suites.


Xuelei

On 9/15/2016 6:21 AM, Wang Weijun wrote:

Confusing. This does not show why jgss is needed. I'll do some
investigation.

Thanks
Max

在 2016年9月14日，23:57，Sergei Kovalev > 写道：


java.lang.module.ResolutionException: Module java.naming not found,
required by java.security.jgss

Re: RFR(M): 8166032: Fix module dependencies for javax.SSL tests

[Wang Weijun]

Confusing. This does not show why jgss is needed. I'll do some investigation. 

Thanks
Max

> 在 2016年9月14日，23:57，Sergei Kovalev  写道：
> 
> java.lang.module.ResolutionException: Module java.naming not found, required 
> by java.security.jgss

Re: RFR(S): 8165689: Fix module dependencies for sun/security/pkcs11/* tests

[Sean Mullan]

Thanks for the information. It would be very useful if you could add 
that additional information as an example into the bug report for future 
reference.


--Sean

On 09/14/2016 11:26 AM, Sergei Kovalev wrote:

Hi Sean,

I'm working for testing minimal JRE image. If I create custom JRE with
java.base only - the tests fail. To emulate such behavior we can use
"--limit-modules java.base" option. In case if we have no module
declaration in tests header the test fails with, e.g. ClassNotFound
exception (see example in attached log). In case we declare appropriate
modules in jtreg header then jtreg suite skip the test and mark it "not
run" in final report. This help me to clean out all "false positive"
error during testing and reduce time that I spend to failures analysis.


14.09.16 18:20, Sean Mullan wrote:

Looks fine to me, but can you explain in more detail why the extra
dependencies are needed, or an example using --limit-modules? These
tests are not failing regularly now, so when do the missing
dependencies cause failures?

Thanks,
Sean

On 09/13/2016 08:34 AM, Sergei Kovalev wrote:

Hello team,

This is re-request for review of very small changes. Could somebody take
a look?


08.09.16 17:03, Sergei Kovalev wrote:

Hello team,

Could you please review the fix for below CR:

Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165689
WebRev: http://cr.openjdk.java.net/~skovalev/8165689/webrev.00/

Goal: make test possible to run with "--limit-modules" flag.
Summary: added @modules tag into jtreg header if applicable.

Re: RFR(S): 8165689: Fix module dependencies for sun/security/pkcs11/* tests

[Sergei Kovalev]

Answered in other thread


14.09.16 18:54, Wang Weijun wrote:
Sorry I was thinking about another bug on TLS tests -- 8166032. What 
exception is thrown there if the jgss module is missing?


Thanks
Max

在 2016年9月14日，23:44，Wang Weijun > 写道：


The example shows jdk.crypto.pkcs11 is needed, but I still don't know 
why java.security.jgss is. Can you give another example where jgss 
must be present?


Thanks
Max


--
With best regards,
Sergei

Re: RFR(M): 8166032: Fix module dependencies for javax.SSL tests

[Sergei Kovalev]

here it is an example

 jtreg -verbose:all -jdk /home/skovalev/TRASH/jdk-9 
-javaoptions:"--limit-modules java.base" 
/home/skovalev/repos/jdk9-dev/jdk/test/javax/net/ssl/TLSv11/TLSHandshakeTest.java



STDOUT:
Error occurred during initialization of VM
java.lang.module.ResolutionException: Module java.naming not found, 
required by java.security.jgss

at java.lang.module.Resolver.fail(java.base@9-ea/Resolver.java:790)
at 
java.lang.module.Resolver.resolve(java.base@9-ea/Resolver.java:138)
at 
java.lang.module.Resolver.resolveRequires(java.base@9-ea/Resolver.java:108)
at 
java.lang.module.Configuration.resolveRequiresAndUses(java.base@9-ea/Configuration.java:370)
at 
java.lang.module.ModuleDescriptor$1.resolveRequiresAndUses(java.base@9-ea/ModuleDescriptor.java:1986)
at 
jdk.internal.module.ModuleBootstrap.boot(java.base@9-ea/ModuleBootstrap.java:263)

at java.lang.System.initPhase2(java.base@9-ea/System.java:1927)

Sorry I was thinking about another bug on TLS tests -- 8166032. What 
exception is thrown there if the jgss module is missing?


Thanks
Max

在 2016年9月14日，23:44，Wang Weijun > 写道：


The example shows jdk.crypto.pkcs11 is needed, but I still don't know 
why java.security.jgss is. Can you give another example where jgss 
must be present?


Thanks
Max


14.09.16 16:56, Wang Weijun wrote:

I also have no idea why these are needed:

+ * @modules java.security.jgss
+ *  jdk.security.auth

Do the test uses KRB5-related cipher suites?

Thanks
Max


On Sep 14, 2016, at 8:54 PM, Xuelei Fan  wrote:

Hi Sergei,

Thanks for the update.  The fix looks fine to me.  However, I'm not sure why some tests need the 
"/sun/security/krb5/auto" libraries and the related modules.  As you were already there, 
would you mind help to test whether the "/sun/security/krb5/auto" library can be removed 
for some tests?

Thanks,
Xuelei

On 9/14/2016 8:22 PM, Sergei Kovalev wrote:

Hello Team,

Could you please review below fix for

Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166032
Code review: http://cr.openjdk.java.net/~skovalev/8166032/webrev.00/

Issue: The test should be able to pass or skipped by JTreg test suite if
required modules have not been included in custom JRE.
Solution: added '@modules' tags and appropriate module list to tests
header.
Testing done locally using JTregt test suite.



--
With best regards,
Sergei

Re: RFR(S): 8165689: Fix module dependencies for sun/security/pkcs11/* tests

[Wang Weijun]

Sorry I was thinking about another bug on TLS tests -- 8166032. What exception 
is thrown there if the jgss module is missing?

Thanks
Max

> 在 2016年9月14日，23:44，Wang Weijun  写道：
> 
> The example shows jdk.crypto.pkcs11 is needed, but I still don't know why 
> java.security.jgss is. Can you give another example where jgss must be 
> present?
> 
> Thanks
> Max
> 
>> 在 2016年9月14日，23:26，Sergei Kovalev  写道：
>> 
>> Hi Sean,
>> 
>> I'm working for testing minimal JRE image. If I create custom JRE with 
>> java.base only - the tests fail. To emulate such behavior we can use 
>> "--limit-modules java.base" option. In case if we have no module declaration 
>> in tests header the test fails with, e.g. ClassNotFound exception (see 
>> example in attached log). In case we declare appropriate modules in jtreg 
>> header then jtreg suite skip the test and mark it "not run" in final report. 
>> This help me to clean out all "false positive" error during testing and 
>> reduce time that I spend to failures analysis.
>> 
>> 
>> 14.09.16 18:20, Sean Mullan wrote:
>>> Looks fine to me, but can you explain in more detail why the extra 
>>> dependencies are needed, or an example using --limit-modules? These tests 
>>> are not failing regularly now, so when do the missing dependencies cause 
>>> failures?
>>> 
>>> Thanks,
>>> Sean
>>> 
 On 09/13/2016 08:34 AM, Sergei Kovalev wrote:
 Hello team,
 
 This is re-request for review of very small changes. Could somebody take
 a look?
 
 
 08.09.16 17:03, Sergei Kovalev wrote:
> Hello team,
> 
> Could you please review the fix for below CR:
> 
> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165689
> WebRev: http://cr.openjdk.java.net/~skovalev/8165689/webrev.00/
> 
> Goal: make test possible to run with "--limit-modules" flag.
> Summary: added @modules tag into jtreg header if applicable.
> 
 
>> 
>> -- 
>> With best regards,
>> Sergei
>> 
>> 

Re: RFR(S): 8165689: Fix module dependencies for sun/security/pkcs11/* tests

[Wang Weijun]

The example shows jdk.crypto.pkcs11 is needed, but I still don't know why 
java.security.jgss is. Can you give another example where jgss must be present?

Thanks
Max

> 在 2016年9月14日，23:26，Sergei Kovalev  写道：
> 
> Hi Sean,
> 
> I'm working for testing minimal JRE image. If I create custom JRE with 
> java.base only - the tests fail. To emulate such behavior we can use 
> "--limit-modules java.base" option. In case if we have no module declaration 
> in tests header the test fails with, e.g. ClassNotFound exception (see 
> example in attached log). In case we declare appropriate modules in jtreg 
> header then jtreg suite skip the test and mark it "not run" in final report. 
> This help me to clean out all "false positive" error during testing and 
> reduce time that I spend to failures analysis.
> 
> 
> 14.09.16 18:20, Sean Mullan wrote:
>> Looks fine to me, but can you explain in more detail why the extra 
>> dependencies are needed, or an example using --limit-modules? These tests 
>> are not failing regularly now, so when do the missing dependencies cause 
>> failures?
>> 
>> Thanks,
>> Sean
>> 
>>> On 09/13/2016 08:34 AM, Sergei Kovalev wrote:
>>> Hello team,
>>> 
>>> This is re-request for review of very small changes. Could somebody take
>>> a look?
>>> 
>>> 
>>> 08.09.16 17:03, Sergei Kovalev wrote:
 Hello team,
 
 Could you please review the fix for below CR:
 
 Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165689
 WebRev: http://cr.openjdk.java.net/~skovalev/8165689/webrev.00/
 
 Goal: make test possible to run with "--limit-modules" flag.
 Summary: added @modules tag into jtreg header if applicable.
 
>>> 
> 
> -- 
> With best regards,
> Sergei
> 
> 

Re: RFR(S): 8165689: Fix module dependencies for sun/security/pkcs11/* tests

[Sergei Kovalev]

Hi Sean,

I'm working for testing minimal JRE image. If I create custom JRE with 
java.base only - the tests fail. To emulate such behavior we can use 
"--limit-modules java.base" option. In case if we have no module 
declaration in tests header the test fails with, e.g. ClassNotFound 
exception (see example in attached log). In case we declare appropriate 
modules in jtreg header then jtreg suite skip the test and mark it "not 
run" in final report. This help me to clean out all "false positive" 
error during testing and reduce time that I spend to failures analysis.



14.09.16 18:20, Sean Mullan wrote:
Looks fine to me, but can you explain in more detail why the extra 
dependencies are needed, or an example using --limit-modules? These 
tests are not failing regularly now, so when do the missing 
dependencies cause failures?


Thanks,
Sean

On 09/13/2016 08:34 AM, Sergei Kovalev wrote:

Hello team,

This is re-request for review of very small changes. Could somebody take
a look?


08.09.16 17:03, Sergei Kovalev wrote:

Hello team,

Could you please review the fix for below CR:

Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165689
WebRev: http://cr.openjdk.java.net/~skovalev/8165689/webrev.00/

Goal: make test possible to run with "--limit-modules" flag.
Summary: added @modules tag into jtreg header if applicable.





--
With best regards,
Sergei

#Test Results (version 2)
#Fri Sep 09 04:42:50 MSK 2016
#-testdescription-
$file=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher/ReinitCipher.java
$root=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test
author=Andreas Sterbenz
keywords=bug4856966 randomness othervm
library=..
run=USER_SPECIFIED main/othervm ReinitCipher\nUSER_SPECIFIED main/othervm 
ReinitCipher sm\n
source=ReinitCipher.java
title=

#-environment-

#-testresult-
description=file\:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher/ReinitCipher.java
elapsed=1878 0\:00\:01.878
end=Fri Sep 09 04\:42\:50 MSK 2016
environment=regtest
execStatus=Failed. Execution failed\: `main' threw exception\: 
java.security.NoSuchProviderException\: No PKCS11 provider available
harnessLoaderMode=Classpath Loader
harnessVariety=Full Bundle
hostname=slowpoke.ru.oracle.com
javatestOS=Linux 3.2.0-38-generic (amd64)
javatestVersion=4.6
jtregVersion=jtreg 4.2 fcs b03
script=com.sun.javatest.regtest.RegressionScript
sections=script_messages build compile main
start=Fri Sep 09 04\:42\:48 MSK 2016
test=sun/security/pkcs11/Cipher/ReinitCipher.java
testJDK=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk
totalTime=1882
user.name=hudson
work=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/sun/security/pkcs11/Cipher

#section:script_messages
--messages:(8/585)--
JDK under test: 
/var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk
java version "9-internal"
Java(TM) SE Runtime Environment (build 
9-internal+0-2016-09-08-021245.hudson.jake)
Java HotSpot(TM) 64-Bit Server VM (build 
9-internal+0-2016-09-08-021245.hudson.jake, mixed mode)

Library ..; kind: packages
   source directory: 
/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11
   class directory: 
/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11

#section:build
--messages:(5/137)--
command: build ReinitCipher
reason: Named class compiled on demand
Test directory:
  compile: ReinitCipher
elapsed time (seconds): 1.299
result: Passed. Build successful

#section:compile
--messages:(4/214)--
command: compile 
/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher/ReinitCipher.java
reason: .class file out of date or does not exist
Mode: othervm
elapsed time (seconds): 1.291
--configuration:(6/485)--
javac compilation environment
  limit modules: java.base 
  class path:
/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher
 
 
/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11/Cipher
 
 
/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11
 

--rerun:(20/2314)*--
HOME=/var/lib/hudson \\
JTREG_HOME=/var/www/hudson/ws/workspace/MinimalDepsRun/jtreg \\
LANG=en_US.UTF-8 \\
PATH=/bin:/usr/bin \\

/var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk/bin/javac
 \\

-J-Dtest.src=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher
 \\

Re: RFR(S): 8165689: Fix module dependencies for sun/security/pkcs11/* tests

[Sean Mullan]

Looks fine to me, but can you explain in more detail why the extra 
dependencies are needed, or an example using --limit-modules? These 
tests are not failing regularly now, so when do the missing dependencies 
cause failures?


Thanks,
Sean

On 09/13/2016 08:34 AM, Sergei Kovalev wrote:

Hello team,

This is re-request for review of very small changes. Could somebody take
a look?


08.09.16 17:03, Sergei Kovalev wrote:

Hello team,

Could you please review the fix for below CR:

Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165689
WebRev: http://cr.openjdk.java.net/~skovalev/8165689/webrev.00/

Goal: make test possible to run with "--limit-modules" flag.
Summary: added @modules tag into jtreg header if applicable.

Re: RFR(M): 8166032: Fix module dependencies for javax.SSL tests

[Xuelei Fan]

OK.  Looks fine to me.

Thanks,
Xuelei

On 9/14/2016 9:58 PM, Sergei Kovalev wrote:

Hi Xuelei,

I discovered 53 tests in javax/net/ssl folder that refer to
/sun/security/krb5/auto. In general it is about 10 unique tests. All the
tests depends on KDC class. In other places the tests repeated with
different set of environment variable. e.g.
"-Dtest.security.protocol=TLSv1.1", etc.

So I cannot remove reference to the library.


14.09.16 15:54, Xuelei Fan wrote:

Hi Sergei,

Thanks for the update.  The fix looks fine to me.  However, I'm not
sure why some tests need the "/sun/security/krb5/auto" libraries and
the related modules.  As you were already there, would you mind help
to test whether the "/sun/security/krb5/auto" library can be removed
for some tests?

Thanks,
Xuelei

On 9/14/2016 8:22 PM, Sergei Kovalev wrote:

Hello Team,

Could you please review below fix for

Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166032
Code review: http://cr.openjdk.java.net/~skovalev/8166032/webrev.00/

Issue: The test should be able to pass or skipped by JTreg test suite if
required modules have not been included in custom JRE.
Solution: added '@modules' tags and appropriate module list to tests
header.
Testing done locally using JTregt test suite.

Re: RFR(M): 8166032: Fix module dependencies for javax.SSL tests

[Sergei Kovalev]

14.09.16 16:56, Wang Weijun wrote:

I also have no idea why these are needed:

+ * @modules java.security.jgss
+ *  jdk.security.auth

Do the test uses KRB5-related cipher suites?

The tests using /sun/security/krb5/auto. Looks like it is the root cause.


Thanks
Max


On Sep 14, 2016, at 8:54 PM, Xuelei Fan  wrote:

Hi Sergei,

Thanks for the update.  The fix looks fine to me.  However, I'm not sure why some tests need the 
"/sun/security/krb5/auto" libraries and the related modules.  As you were already there, 
would you mind help to test whether the "/sun/security/krb5/auto" library can be removed 
for some tests?

Thanks,
Xuelei

On 9/14/2016 8:22 PM, Sergei Kovalev wrote:

Hello Team,

Could you please review below fix for

Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166032
Code review: http://cr.openjdk.java.net/~skovalev/8166032/webrev.00/

Issue: The test should be able to pass or skipped by JTreg test suite if
required modules have not been included in custom JRE.
Solution: added '@modules' tags and appropriate module list to tests
header.
Testing done locally using JTregt test suite.



--
With best regards,
Sergei

Re: RFR(M): 8166032: Fix module dependencies for javax.SSL tests

[Sergei Kovalev]

Hi Xuelei,

I discovered 53 tests in javax/net/ssl folder that refer to 
/sun/security/krb5/auto. In general it is about 10 unique tests. All the 
tests depends on KDC class. In other places the tests repeated with 
different set of environment variable. e.g. 
"-Dtest.security.protocol=TLSv1.1", etc.


So I cannot remove reference to the library.


14.09.16 15:54, Xuelei Fan wrote:

Hi Sergei,

Thanks for the update.  The fix looks fine to me.  However, I'm not 
sure why some tests need the "/sun/security/krb5/auto" libraries and 
the related modules.  As you were already there, would you mind help 
to test whether the "/sun/security/krb5/auto" library can be removed 
for some tests?


Thanks,
Xuelei

On 9/14/2016 8:22 PM, Sergei Kovalev wrote:

Hello Team,

Could you please review below fix for

Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166032
Code review: http://cr.openjdk.java.net/~skovalev/8166032/webrev.00/

Issue: The test should be able to pass or skipped by JTreg test suite if
required modules have not been included in custom JRE.
Solution: added '@modules' tags and appropriate module list to tests
header.
Testing done locally using JTregt test suite.



--
With best regards,
Sergei

Re: RFR(M): 8166032: Fix module dependencies for javax.SSL tests

[Wang Weijun]

I also have no idea why these are needed:

+ * @modules java.security.jgss
+ *  jdk.security.auth

Do the test uses KRB5-related cipher suites?

Thanks
Max

> On Sep 14, 2016, at 8:54 PM, Xuelei Fan  wrote:
> 
> Hi Sergei,
> 
> Thanks for the update.  The fix looks fine to me.  However, I'm not sure why 
> some tests need the "/sun/security/krb5/auto" libraries and the related 
> modules.  As you were already there, would you mind help to test whether the 
> "/sun/security/krb5/auto" library can be removed for some tests?
> 
> Thanks,
> Xuelei
> 
> On 9/14/2016 8:22 PM, Sergei Kovalev wrote:
>> Hello Team,
>> 
>> Could you please review below fix for
>> 
>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166032
>> Code review: http://cr.openjdk.java.net/~skovalev/8166032/webrev.00/
>> 
>> Issue: The test should be able to pass or skipped by JTreg test suite if
>> required modules have not been included in custom JRE.
>> Solution: added '@modules' tags and appropriate module list to tests
>> header.
>> Testing done locally using JTregt test suite.
>> 

Re: RFR(M): 8166032: Fix module dependencies for javax.SSL tests

[Xuelei Fan]

Hi Sergei,

Thanks for the update.  The fix looks fine to me.  However, I'm not sure 
why some tests need the "/sun/security/krb5/auto" libraries and the 
related modules.  As you were already there, would you mind help to test 
whether the "/sun/security/krb5/auto" library can be removed for some tests?


Thanks,
Xuelei

On 9/14/2016 8:22 PM, Sergei Kovalev wrote:

Hello Team,

Could you please review below fix for

Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166032
Code review: http://cr.openjdk.java.net/~skovalev/8166032/webrev.00/

Issue: The test should be able to pass or skipped by JTreg test suite if
required modules have not been included in custom JRE.
Solution: added '@modules' tags and appropriate module list to tests
header.
Testing done locally using JTregt test suite.

RFR(M): 8166032: Fix module dependencies for javax.SSL tests

[Sergei Kovalev]

Hello Team,

Could you please review below fix for

Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166032
Code review: http://cr.openjdk.java.net/~skovalev/8166032/webrev.00/

Issue: The test should be able to pass or skipped by JTreg test suite if 
required modules have not been included in custom JRE.

Solution: added '@modules' tags and appropriate module list to tests header.
Testing done locally using JTregt test suite.

--
With best regards,
Sergei

Do your NSS DLLs on Windows have execute permission?

[Weijun Wang]

I see PKCS11 tests fail on my Windows 10 after JDK-8165946 [1]. After 
discussing with John (who worked on the bug) I found my NSS DLLs do not 
have the execute permission bit and his have.


Mine is -rw-r--r--, and his is -rwxrwx---+.

I am using cygwin on Windows 10 64-bit, and I use hg inside cygwin to 
clone the repo. My umask is 0022.


Do you have that x? If yes, what's wrong with my environment? If no, do 
the tests run fine on your machine? For example, I just tried 
sun/security/pkcs11/Cipher/TestSymmCiphers.java and it fails.


Thanks
Max

[1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/15badd72caae

Re: [9] RFR: 8165660: Remove the intermittent keyword from sun/security/krb5/auto/MaxRetries.java

[Weijun Wang]

After some thinking, I am OK with the change now. Please remove the keyword.

Thanks
Max

On 9/13/2016 19:11, Weijun Wang wrote:

Is there a criteria on when to add and when to remove this keyword? Due
to the characteristics (timeout, ICMP) of these tests, they still have a
chance to fail.

If we keep the keyword there, will it be any bad?

Thanks
Max

On 9/13/2016 18:56, Sibabrata Sahoo wrote:

Hi,



Please review the patch for,



JBS: https://bugs.openjdk.java.net/browse/JDK-8165660

Webrev: http://cr.openjdk.java.net/~ssahoo/8165660/webrev.00/



Description:

This is a simple fix for removing  intermittent keyword from
sun/security/krb5/auto/MaxRetries.java file.





Thanks,

Siba

Re: RFR[9] JDK-8077138: Some PKCS11 tests fail because NSS library is not initialized

[John Jiang]

Hi,

On 2016/9/14 14:59, Weijun Wang wrote:

Hi John

I just noticed this webrev request.

After syncing with jdk9/dev, the PKCS11 tests still fail on my 64-bit 
Windows 10 machine. I had always thought [1] the failure is due to the 
DLLs without the executable bit. In fact, after I chmod a+x them, the 
tests pass.


How did you confirm your change works? Did the test fail with the old 
DLLs on your test machine and succeed with the new ones?
I did run JPRT on PKCS11 tests with/without the patch. And the results 
are expected.

Exactly, the tests failed without the patch, and they passed with the patch.
And Mach5 have run the tests after the patch was pushed, no PKCS11 test 
failure was found.


Best regards,
John Jiang


Thanks
Max

[1] 
https://bugs.openjdk.java.net/browse/JDK-8023434?focusedCommentId=13860118=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13860118


On 9/13/2016 17:43, John Jiang wrote:

Hi,
Please review this patch for fixing JDK-8077138.
The solution is re-building NSS libraries with VS2013, and then the new
NSS DLLs can depend on msvcr120.dll, which is already distributed with
JDK 9.

And please note that, this patch also removes the PKCS11 tests from
ProblemList.txt, though these tests have another issue JDK-8023434.
JDK-8023434 is related to Solaris, but the PKCS11 tests are marked with
windows-all. So, I think it's no meaning to keep such items. Then, these
tests will really be executed on Windows platforms.

Webrev: http://cr.openjdk.java.net/~jjiang/8077138/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8077138

Best regards,
John Jiang

Re: RFR[9] JDK-8077138: Some PKCS11 tests fail because NSS library is not initialized

[Weijun Wang]

Hi John

I just noticed this webrev request.

After syncing with jdk9/dev, the PKCS11 tests still fail on my 64-bit 
Windows 10 machine. I had always thought [1] the failure is due to the 
DLLs without the executable bit. In fact, after I chmod a+x them, the 
tests pass.


How did you confirm your change works? Did the test fail with the old 
DLLs on your test machine and succeed with the new ones?


Thanks
Max

[1] 
https://bugs.openjdk.java.net/browse/JDK-8023434?focusedCommentId=13860118=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13860118


On 9/13/2016 17:43, John Jiang wrote:

Hi,
Please review this patch for fixing JDK-8077138.
The solution is re-building NSS libraries with VS2013, and then the new
NSS DLLs can depend on msvcr120.dll, which is already distributed with
JDK 9.

And please note that, this patch also removes the PKCS11 tests from
ProblemList.txt, though these tests have another issue JDK-8023434.
JDK-8023434 is related to Solaris, but the PKCS11 tests are marked with
windows-all. So, I think it's no meaning to keep such items. Then, these
tests will really be executed on Windows platforms.

Webrev: http://cr.openjdk.java.net/~jjiang/8077138/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8077138

Best regards,
John Jiang