[8]: help on PKCS#11 tests build

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.<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
>




More information about the build-dev mailing list