[8]: help on PKCS#11 tests build

[Bradford Wetmore]

IIRC, and in case it wasn't clear from reading the responses, the 
permission changes are done by the Makefiles (e.g. 
jdk/test/Makefile:193), and not by JTREG itself.

I agree with Jon's comment, perhaps a .dll copy to the temporary working 
directory is in order.  That would save people trying to figure out why 
their tests are failing when running under a .hg directory with the 
makefiles, or when using JTREG directly.

I'm not sure how many .dlls there are in the test dirs (including closed 
where most probably live), but should probably be done all together 
instead of by functional area.

Brad



On 12/4/2013 10:40 AM, Jonathan Gibbons wrote:
> 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.<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
>>
>