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.dui...@oracle.com>:
On Dec 4 2013, at 06:06 , Magnus Ihse Bursie
<magnus.ihse.bur...@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.kampb...@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.<init>(SunPKCS11.java:376)
at sun.security.pkcs11.SunPKCS11.<init>(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.<init>(PKCS11.java:138)
at
sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:313)
... 9 more
