-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
P4
-
None
-
Affects Version/s: 8
-
Component/s: hotspot
-
None
-
aarch64
-
linux
how to reproduce:
$ # get any jdk8 aarch64 fastdebug
$ sbtv=1.11.4
$ wget https://github.com/sbt/sbt/releases/download/v$sbtv/sbt-$sbtv.tgz
$ tar -xf sbt-$sbtv.tgz
$ git clone https://github.com/scala/scala.git
$ cd scala/
$ git checkout 2.13.x #to fail on tip of development branch (not fixed, 1.11.2025)
$ # git checkout v2.13.16 # to pass
$ git checkout v2.13.17 # to fail on release tag
$ ../sbt/bin/sbt --java-home path_to_yours_fastdebug_jdk_aarch64 --no-colors "partest test/files/jvm/natives.scala"
$ # --no-colors have no impact to pass/fail but is somehow more readable
$ # to run some exact test is faster then build whole scala
$ # it is most likely to fail also on other tests, but I have not tried
$ # note, that to sigsev the VM may take longer time, then to pass the compilation and run (fail) the test, jvm seems to be stuck somewhere
What I had tried so far:
- other jdks, 11-25 works fine, fastdebug and release
- other architectures then aarch64 works fine also on jdk8
- including windows x64. excluding any mac or windows arm64
- jdk8 in release mode works fine everywhere to
- tried on rhel7, rhel8,rhel9, rhel10 and fedora
- tried with jdk8 built on rhel7, rhel8 and rhel9
Long story short, issue seems to be really isolated on Linux aarch64 jdk8 fastdebug
Oldest "working" jdk8 I found with aarch64 was 1.8.0.342.b07. Older jdk8 can no longer build scala due to missing classes.
Final verification was done on:
java-1.8.0-openjdk-portable-devel-fastdebug-1.8.0.342.b07-1.el7openjdkportable.aarch64.rpm
oldest after 322 found in brew
java-1.8.0-openjdk-portable-devel-fastdebug-1.8.0.345.b01-1.el7openjdkportable.aarch64.rpm
java-1.8.0-openjdk-portable-devel-fastdebug-1.8.0.372.b07-2.el8.aarch64.rpm
java-1.8.0-openjdk-portable-devel-fastdebug-1.8.0.382.b05-2.el7openjdkportable.aarch64.rpm
java-1.8.0-openjdk-portable-devel-fastdebug-1.8.0.382.b05-2.el8.aarch64.rpm
java-1.8.0-openjdk-portable-devel-fastdebug-1.8.0.462.b08-2.el8.aarch64.rpm
java-1.8.0-openjdk-portable-devel-fastdebug-1.8.0.472.b08-1.el8.aarch64.rpm
All those jdks crashes during build of scala v2.13.17, on aarch64 by jdk8. All those jdks pass on v2.13.16.
On 2.13.16 it passes the ctitical section. You can see it "ok" and behind the crashing section if you see something like:
# starting 1 test in jvm
Note: test execution will be non-parallel under -Dpartest.exec.in.process
!! 1 - jvm/natives.scala [non-zero exit code][duration 34.78s]
##### Log file '/home/tester/scala/test/files/jvm/natives-jvm.log' from failed test #####
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/tester/scala/test/files/jvm/libnatives-64.so: /home/tester/scala/test/files/jvm/libnatives-64.so: cannot open shared object file: No such file or directory (Possible cause: can't load AMD 64-bit .so on a AARCH64-bit platform)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
...
at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)
# 0/1 passed, 1 failed in jvm
# A test failed. To update the check file:
partest --update-check jvm/natives.scala
[error] Failed: Total 1, Failed 1, Errors 0, Passed 0
[error] Failed tests:
[error] partest
[warn] In the last 247 seconds, 27.534 (11.2%) were spent in GC. [Heap: 1.20GB free of 1.65GB, max 1.78GB] Consider increasing the JVM heap using `-Xmx` or try a different collector, e.g. `-XX:+UseG1GC`, for better performance.
[error] (test / IntegrationTest / testOnly) sbt.TestsFailedException: Tests unsuccessful
[error] Total time: 2361 s (39:21), completed Oct 31, 2025 6:56:11 PM
I can provide instructions how to pass the test, but it is not trivial, and afaik not necessary for this bug.
Note, that scala is using sbt as it needs, not the one you downloade.
See that this example wget sbt 1.11.4 , but the run of checkouted 2.13.16 is using "welcome to sbt 1.10.7..." and the 2.13.17 is using "welcome to sbt 1.11.7..".
The sbt download main jar as it needs per scala build definitions. The different version of sbt may be one of the reasons, but I doubt it. From my unexperiecned check of hserr files, the crash is in compiler.
On 2.13.17 there is obvious SIGSEV
$ # get any jdk8 aarch64 fastdebug
$ sbtv=1.11.4
$ wget https://github.com/sbt/sbt/releases/download/v$sbtv/sbt-$sbtv.tgz
$ tar -xf sbt-$sbtv.tgz
$ git clone https://github.com/scala/scala.git
$ cd scala/
$ git checkout 2.13.x #to fail on tip of development branch (not fixed, 1.11.2025)
$ # git checkout v2.13.16 # to pass
$ git checkout v2.13.17 # to fail on release tag
$ ../sbt/bin/sbt --java-home path_to_yours_fastdebug_jdk_aarch64 --no-colors "partest test/files/jvm/natives.scala"
$ # --no-colors have no impact to pass/fail but is somehow more readable
$ # to run some exact test is faster then build whole scala
$ # it is most likely to fail also on other tests, but I have not tried
$ # note, that to sigsev the VM may take longer time, then to pass the compilation and run (fail) the test, jvm seems to be stuck somewhere
What I had tried so far:
- other jdks, 11-25 works fine, fastdebug and release
- other architectures then aarch64 works fine also on jdk8
- including windows x64. excluding any mac or windows arm64
- jdk8 in release mode works fine everywhere to
- tried on rhel7, rhel8,rhel9, rhel10 and fedora
- tried with jdk8 built on rhel7, rhel8 and rhel9
Long story short, issue seems to be really isolated on Linux aarch64 jdk8 fastdebug
Oldest "working" jdk8 I found with aarch64 was 1.8.0.342.b07. Older jdk8 can no longer build scala due to missing classes.
Final verification was done on:
java-1.8.0-openjdk-portable-devel-fastdebug-1.8.0.342.b07-1.el7openjdkportable.aarch64.rpm
oldest after 322 found in brew
java-1.8.0-openjdk-portable-devel-fastdebug-1.8.0.345.b01-1.el7openjdkportable.aarch64.rpm
java-1.8.0-openjdk-portable-devel-fastdebug-1.8.0.372.b07-2.el8.aarch64.rpm
java-1.8.0-openjdk-portable-devel-fastdebug-1.8.0.382.b05-2.el7openjdkportable.aarch64.rpm
java-1.8.0-openjdk-portable-devel-fastdebug-1.8.0.382.b05-2.el8.aarch64.rpm
java-1.8.0-openjdk-portable-devel-fastdebug-1.8.0.462.b08-2.el8.aarch64.rpm
java-1.8.0-openjdk-portable-devel-fastdebug-1.8.0.472.b08-1.el8.aarch64.rpm
All those jdks crashes during build of scala v2.13.17, on aarch64 by jdk8. All those jdks pass on v2.13.16.
On 2.13.16 it passes the ctitical section. You can see it "ok" and behind the crashing section if you see something like:
# starting 1 test in jvm
Note: test execution will be non-parallel under -Dpartest.exec.in.process
!! 1 - jvm/natives.scala [non-zero exit code][duration 34.78s]
##### Log file '/home/tester/scala/test/files/jvm/natives-jvm.log' from failed test #####
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/tester/scala/test/files/jvm/libnatives-64.so: /home/tester/scala/test/files/jvm/libnatives-64.so: cannot open shared object file: No such file or directory (Possible cause: can't load AMD 64-bit .so on a AARCH64-bit platform)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
...
at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)
# 0/1 passed, 1 failed in jvm
# A test failed. To update the check file:
partest --update-check jvm/natives.scala
[error] Failed: Total 1, Failed 1, Errors 0, Passed 0
[error] Failed tests:
[error] partest
[warn] In the last 247 seconds, 27.534 (11.2%) were spent in GC. [Heap: 1.20GB free of 1.65GB, max 1.78GB] Consider increasing the JVM heap using `-Xmx` or try a different collector, e.g. `-XX:+UseG1GC`, for better performance.
[error] (test / IntegrationTest / testOnly) sbt.TestsFailedException: Tests unsuccessful
[error] Total time: 2361 s (39:21), completed Oct 31, 2025 6:56:11 PM
I can provide instructions how to pass the test, but it is not trivial, and afaik not necessary for this bug.
Note, that scala is using sbt as it needs, not the one you downloade.
See that this example wget sbt 1.11.4 , but the run of checkouted 2.13.16 is using "welcome to sbt 1.10.7..." and the 2.13.17 is using "welcome to sbt 1.11.7..".
The sbt download main jar as it needs per scala build definitions. The different version of sbt may be one of the reasons, but I doubt it. From my unexperiecned check of hserr files, the crash is in compiler.
On 2.13.17 there is obvious SIGSEV