running tests from make causes spurious repo changes

[Erik Joelsson]

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.

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