[8]: help on PKCS#11 tests build (original) (raw)

Jonathan Gibbons jonathan.gibbons at oracle.com
Wed Dec 4 18:40:51 UTC 2013

It should also be the case that the tests should run if the entire test/ directory (all files and directories) were readonly, so if code is modifying files in place or creating new files anywhere in the test directory, that should be regarded as a Bad Thing and fixed.

-- Jon

On 12/04/2013 10:27 AM, Francis ANDRE wrote:

Agreed with Magnus.... the setting of the executable bits should be made explicitly somewhere to avoid such error...

Francis Le 04/12/2013 19:05, Magnus Ihse Bursie a écrit : So at least you find a likely cause for the issues Francis are seeing. :)

It feels a bit weird juggling around with permissions like that, but maybe there was no clear use-case for running this from hg? /Magnus

4 dec 2013 kl. 16:38 skrev Mike Duigou <mike.duigou at oracle.com>:

On Dec 4 2013, at 06:06 , Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote: On 2013-11-22 10:12, Mike Duigou wrote: the jdk/test/Makefile is normally responsible for setting the executable flags on those files but only does so before running the tests. If you are executing jtreg directly then the files aren't being made executable. Hm, are you saying jtreg is setting executable flags for file in the hg repo? Isn't that a risk that it will be checked in if you're not careful? I just checked and discovered that the executable bits setting is done only if the hg directory is absent. So setting the executable bits is likely only being done only on oracle's internal test machines which get their test source as a tarball rather than via an hg clone. I am not familiar enough with the history to know what is expected to happen when tests are run from an hg clone. It looks like the choices are to temporarily or permanently set the executable flags to allow the tests to run. Mike /Magnus Mike

On Nov 21 2013, at 20:49 , Francis ANDRE <francis.andre.kampbell at orange.fr> wrote:

Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:313) ... 9 more

More information about the build-dev mailing list