running tests from make causes spurious repo changes

Erik Joelsson erik.joelsson at oracle.com
Wed Sep 27 09:37:37 UTC 2017



On 2017-09-27 11:36, Erik Joelsson wrote:
> Ah good find and I stand corrected. That relative path check does need 
> to change for this to continue working as before.
>
> What I don't understand is why the chmod is needed and why it's only 
> done when not running from a hg repo. We don't allow executable files 
> in the repository so if +x was required, then the tests would fail if 
> run from an hg repo.
>
I realize this was explained in the comment as I was sending this.
/Erik
> /Erik
>
>
> On 2017-09-27 11:28, Maurizio Cimadamore wrote:
>> I did a bit of digging on this one, I found out that the permissions 
>> are indeed changed by make - see test/TestCommon.gmk:
>>
>> # Prep for output
>> # Change execute permissions on shared library files.
>> # Files in repositories should never have execute permissions, but
>> # there are some tests that have pre-built shared libraries, and these
>> # windows dll files must have execute permission. Adding execute
>> # permission may happen automatically on windows when using certain
>> # versions of mercurial but it cannot be guaranteed. And blindly
>> # adding execute permission might be seen as a mercurial 'change', so
>> # we avoid adding execute permission to repository files. But testing
>> # from a plain source tree needs the chmod a+rx. Applying the chmod to
>> # all shared libraries not just dll files. And with CYGWIN and sshd
>> # service, you may need CYGWIN=ntsec for this to work.
>> prep:
>>     @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR)
>>     @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)`
>>     @if [ ! -d $(TEST_ROOT)/../.hg ] ; 
>> then                                   \
>>       $(FIND) $(TEST_ROOT) \( -name \*.dll -o -name \*.DLL -o -name 
>> \*.so \)  \
>>             -exec $(CHMOD) a+rx {} \; 
>> ;                                       \
>>     fi
>>
>>
>> This part seems to be responsible for changing the permissions on the 
>> said lib files. That said, TestCommon.gmk is essentially the same as  
>> it was in jdk10 unconsolidated, but yet the problem cannot be 
>> reporoduced in the latest unconsolidated jdk10 repo. So, I believe 
>> something is up. More specifically, this test:
>>
>> if [ ! -d $(TEST_ROOT)/../.hg ] ; 
>> then                                   \
>>
>> was probably failing before, causing the permission changing branch 
>> not to be taken?
>>
>> Maurizio
>>
>>
>> On 26/09/17 12:10, Maurizio Cimadamore wrote:
>>>
>>>
>>> On 26/09/17 07:13, Alan Bateman wrote:
>>>>
>>>>
>>>> On 25/09/2017 21:35, Maurizio Cimadamore wrote:
>>>>>
>>>>>
>>>>> On 25/09/17 20:58, Alan Bateman wrote:
>>>>>>
>>>>>>
>>>>>> On 25/09/2017 20:11, Jonathan Gibbons wrote:
>>>>>>> Erik,
>>>>>>>
>>>>>>> It could be a feature of the build (i.e. test makefiles) to 
>>>>>>> verify that no source-controlled files were modified in the 
>>>>>>> course of a test run.
>>>>>> Something fishy in this thread as these tests have historically 
>>>>>> not changed the permissions of these libraries. So I'm curious 
>>>>>> how they were run, I wonder in case they were changed by a make 
>>>>>> file instead.
>>>>> make test TEST=jdk_lang
>>>>>
>>>>> AFAIK, this should be the correct way of invoking tests from make?
>>>> I assume this make file must be running chmod, not the tests 
>>>> themselves as otherwise this issue would have been noticed a long 
>>>> time ago. I suspect many people run jtreg directly in their local 
>>>> environment rather than the make file.
>>> Note that I've been running tests this way over the last 2-3 years, 
>>> and this only started to happen after the move to consolidated repo. 
>>> That's why I correlated the two things.
>>>
>>> Maurizio
>>>>
>>>> In any case, these older tests predate build test support for 
>>>> compiling native code and probably should be migrated anyway.
>>>>
>>>> -Alan
>>>
>>
>




More information about the build-dev mailing list