Openjdk-tests: system test on openjdk10 hotspot macos get compiling error.

[sophia-guo]

/Users/jenkins/workspace/openjdk10_hs_systemtest_x86-64_macos/openjdk-tests/systemtest/openjdk-systemtest/openjdk.build/include/top.xml:486: Execute failed: java.io.IOException: Cannot run program "${java8_bindir}/java" (in directory "/Users/jenkins/workspace/openjdk10_hs_systemtest_x86-64_macos/openjdk-tests/systemtest/openjdk-systemtest/openjdk.build"): error=2, No such file or directory

https://ci.adoptopenjdk.net/view/Test_system/job/openjdk10_hs_systemtest_x86-64_macos/120/console

[Mesbah-Alam]

java8_bindir gets set fine on macos when it is JDK8 : https://ci.adoptopenjdk.net/view/Test_system/job/openjdk8_hs_systemtest_x86-64_macos/122/consoleFull

It is not being set on JDK10 - which is what's causing this failure.

[Mesbah-Alam]

The issue is caused because of the fact that the JDK used in the job is not a full SDK but only a 'jre' that doesn't contain javac executable.

Logging into macos1010-x64-2, I see:

/Users/jenkins/workspace/openjdk10_hs_systemtest_x86-64_macos/openjdkbinary/j2sdk-image/bin
DXU773:bin jenkins$ ls
appletviewer    java            jrunscript      orbd            rmid            servertool      unpack200
idlj            jjs             keytool         pack200         rmiregistry     tnameserv

@sophia-guo - any idea why the job is using a macos Java 10 jre and not the full sdk?

[smlambert]

Does systemtest still use whatever is set for JAVA_HOME ? Or do we use the JDK under test to compile test material?

All the machines should have a variety of jdks available for use, but if a jdk10 one is not present (and we are not using the sdk under test / which should be a full one, not a jre), you should check if there is already an openjdk-infrastructure issue for it (boot jdk issues), if not create one.

[Mesbah-Alam]

Systemtest still uses JAVA_HOME, so it expects it to point to the JDK under test. For this failing case, it seems that we are downloading the macos java 10 jre, instead of the full SDK, and placing it under the the location where we'd normally place the SDK under test, e.g. /Users/jenkins/workspace/openjdk10_hs_systemtest_x86-64_macos/openjdkbinary/.

[sophia-guo]

All the build consume both jre and jdk .

15:15:17 unzip file: OpenJDK10U-jre_x64_mac_hotspot_2018-09-12-06-01.tar.gz ...
15:15:18 unzip file: OpenJDK10U_x64_mac_hotspot_2018-09-12-06-01.tar.gz ...

[sophia-guo]

I did see both jars are under the workspace, however didn't see the unjarred folder.

DXU751:openjdkbinary jenkins$ pwd
/Users/jenkins/workspace/openjdk10_hs_systemtest_x86-64_macos/openjdkbinary
DXU751:openjdkbinary jenkins$ ls
OpenJDK10U-jre_x64_mac_hotspot_2018-09-11-06-01.tar.gz  OpenJDK10U_x64_mac_hotspot_2018-09-11-06-01.tar.gz

[Mesbah-Alam]

@sophia-guo - yes, both jre and sdk tar files are there, but only the jre is seen in 'unpacked' form in that location.

DXU773:openjdkbinary jenkins$ pwd
/Users/jenkins/workspace/openjdk10_hs_systemtest_x86-64_macos/openjdkbinary
DXU773:openjdkbinary jenkins$ ls -la
total 469576
drwxr-xr-x  5 jenkins  staff        170 Sep 12 06:15 .
drwxr-xr-x  5 jenkins  staff        170 Sep 12 06:15 ..
-rw-r--r--  1 jenkins  staff   38881651 Sep 12 06:10 OpenJDK10U-jre_x64_mac_hotspot_2018-09-12-06-01.tar.gz
-rw-r--r--  1 jenkins  staff  201536230 Sep 12 06:10 OpenJDK10U_x64_mac_hotspot_2018-09-12-06-01.tar.gz
drwxr-xr-x  9 jenkins  staff        306 Sep 12 06:15 j2sdk-image
DXU773:openjdkbinary jenkins$ cd j2sdk-image/
DXU773:j2sdk-image jenkins$ ls -la
total 8
drwxr-xr-x   9 jenkins  staff   306 Sep 12 06:15 .
drwxr-xr-x   5 jenkins  staff   170 Sep 12 06:15 ..
drwxr-xr-x  15 jenkins  staff   510 Sep 12 06:09 bin
drwxr-xr-x   7 jenkins  staff   238 Sep 12 06:09 conf
drwxr-xr-x  11 jenkins  staff   374 Sep 12 06:09 jdk-10.0.2+13
drwxr-xr-x  58 jenkins  staff  1972 Sep 12 06:09 legal
drwxr-xr-x  51 jenkins  staff  1734 Sep 12 06:09 lib
drwxr-xr-x   5 jenkins  staff   170 Sep 12 06:09 man
-rwxr-xr-x   1 jenkins  staff   998 Sep 12 06:09 release

[Mesbah-Alam]

The SDK was actually un-packed under the un-packed jre folder. So, this is where something is going wrong.

DXU773:j2sdk-image jenkins$ pwd
/Users/jenkins/workspace/openjdk10_hs_systemtest_x86-64_macos/openjdkbinary/j2sdk-image
DXU773:j2sdk-image jenkins$ ls
bin             conf            jdk-10.0.2+13   legal           lib             man             release
DXU773:j2sdk-image jenkins$ cd jdk-10.0.2+13/bin/
DXU773:bin jenkins$ ls -la
total 5968
drwxr-xr-x  43 jenkins  staff    1462 Sep 12 06:09 .
drwxr-xr-x  11 jenkins  staff     374 Sep 12 06:09 ..
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 appletviewer
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 idlj
-rwxr-xr-x   1 jenkins  staff   71932 Sep 12 06:09 jaotc
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jar
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jarsigner
-rwxr-xr-x   1 jenkins  staff   71868 Sep 12 06:09 java
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 javac
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 javadoc
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 javap
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jcmd
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jconsole
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jdb
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jdeprscan
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jdeps
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jhsdb
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jimage
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jinfo
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jjs
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jlink
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jmap
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jmod
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jps
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jrunscript
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jshell
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jstack
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jstat
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 jstatd
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 keytool
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 orbd
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 pack200
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 rmic
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 rmid
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 rmiregistry
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 schemagen
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 serialver
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 servertool
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 tnameserv
-rwxr-xr-x   1 jenkins  staff  106032 Sep 12 06:09 unpack200
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 wsgen
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 wsimport
-rwxr-xr-x   1 jenkins  staff   71900 Sep 12 06:09 xjc

[sophia-guo]

yes, created an issue in build https://github.com/AdoptOpenJDK/openjdk-build/issues/504

[johnoliver]

I assume the logic for extracting the tars is at:

https://github.com/AdoptOpenJDK/openjdk-tests/blob/fe6eea372cadfbf92c8c054ff829474c20705535/get.sh#L175

It does look like this code could be quite brittle as its way of relocating the jdk/jre is to list all of the files in the current directory (./openjdkbinary/) and move them based on their name (if I am interpreting that script correctly).

Note on your failed run you got:

14:15:17 get jdk binary...
14:15:17 mkdir: openjdkbinary: File exists

So that directory was not empty before you started, so anything that was already in there will get listed and moved again.

Does that dir get wiped out between runs? My guess, is there was stuff already there and you are seeing a dir structure that has been built up by multiple runs listing and relocating that dir

[Mesbah-Alam]

I am not sure what exactly openjdkbinary: File exists message entails, but it does not prove no workspace clean up was done prior to build start.

The last openjdk10_hs_systemtest_x86-64_macos build was run today, on Sep 13, 2018 3:11 PM . And it was run on the same machine as the previous build -- macos1010-x64-2: {ip: 74.80.250.173, user: admin}

Looking inside the workspace, the openjdkbinary directory for the latest build was indeed created on the day that build was run, Sept 13th -

/Users/jenkins/workspace/openjdk10_hs_systemtest_x86-64_macos
DXU773:openjdk10_hs_systemtest_x86-64_macos jenkins$ ls -la
total 0
drwxr-xr-x   5 jenkins  staff  170 Sep 13 06:14 .
drwxr-xr-x  24 jenkins  staff  816 Sep 13 07:21 ..
drwxr-xr-x   5 jenkins  staff  170 Sep 13 06:14 jvmtest
drwxr-xr-x  21 jenkins  staff  714 Sep 13 06:14 openjdk-tests
drwxr-xr-x   5 jenkins  staff  170 **Sep 13 06:14** openjdkbinary

This suggests the workspace clean up is happening as expected after all.

[sophia-guo]

I believe we have talked about the naming convention about the jre image @sxa555 https://github.com/AdoptOpenJDK/openjdk-tests/issues/417

https://github.com/AdoptOpenJDK/openjdk-build/pull/331. Tests assume that jre will be named as jre*version*. Now seems jre image naming is updated to jdk-*<version>*-jre. If that's the case we will need to update test script to support this change. @karianna Could you please confirm this?

[karianna]

Paging @johnoliver

[sophia-guo]

Workspace is cleaned up for each build is running. The dir openjdkbinary is created when we grab the sdk from upstream. The messageopenjdkbinary: File exists should not affect following steps, which I will move it to the correct step to stop the confusion.

[johnoliver]

I would try not to be dependent on that the name of the dir inside the tar is, i.e use:

tar xpzf - --strip-components=2 -C "$JDK_DIR"

An example being:

wget -q -O - "https://api.adoptopenjdk.net/v2/binary/releases/openjdk10?os=linux&release=latest&arch=x64" | tar xpzf - --strip-components=2 -C "./a-jdk-dir"

[sophia-guo]

@johnoliver Do you happen to know if unzip have similar option? Or I can google :) thanks.

[johnoliver]

you also have the unzip that may be harder as it does not have strip support. I have tested:

dest=TargetJDKDir; 
zipFile=../foo.zip;

rm -rf "./$dest"; 
mkdir -p "$dest"; 
unzip -d "$dest" $zipFile && f=("$dest"/*) && mv "$dest"/*/* "$dest" && rmdir "${f[@]}"

Shamelessly stolen from: https://superuser.com/questions/518347/equivalent-to-tars-strip-components-1-in-unzip

[sophia-guo]

Thanks @johnoliver ! This is a much better solution as now we need to support test with JDK, JRE, TEST images.

[sophia-guo]

Though the naming convention would be requested to jdk/jre/test tar name as we need to unpack different tar to specific folder.

[Mesbah-Alam]

Do we need to download the JRE? Is it possible to download the full SDK only?

[sophia-guo]

Yes, we do. We would support smoke tests for JRE.