[8]: help on PKCS#11 tests build

[Francis ANDRE]

There are 6 dlls in the test directory

./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll
./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll
./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll
./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll
./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll
./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll

Francis

Le 05/12/2013 03:16, Bradford Wetmore a écrit :
> 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
>>>
>>
>