ORDS 25.1.0 arm64: Broken java installation

[plafue]

linux/arm64 version of container-registry.oracle.com/database/ords:25.1.0 complains about the java installation in the container:

docker run -it --rm -v xxxxxxxxx container-registry.oracle.com/database/ords:25.1.0 config list
INFO : Running Oracle REST Data Services CLI command.


Error: ORDS requires Java 17 and above to run.
       Found Java version .
       Please set JAVA_HOME to appropriate version and update PATH if necessary.

running java -version results in a fatal error:

sh-5.1$ java -version
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x0000ffff9802579c, pid=16, tid=17
#
# JRE version:  (21.0.2+13) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0.2+13-LTS-jvmci-23.1-b30, mixed mode, sharing, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# j  java.lang.System.registerNatives()V+0 java.base
#
# Core dump will be written. Default location: /opt/oracle/ords/core
#
# An error report file with more information is saved as:
# /opt/oracle/ords/hs_err_pid16.log
[0.018s][warning][os] Loading hsdis library failed
#
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted (core dumped)
sh-5.1$

[GlenORCL]

Same issue for me from container-registry.oracle.com/database/ords-developer:24.4.0

java -version
# 
# A fatal error has been detected by the Java Runtime Environment: 
#
#  SIGILL (0x4) at pc=0x0000ffff87f3fc5c, pid=214, tid=215
#
# JRE version:  (21.0.3+7) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0.3+7-LTS-152, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# j  java.lang.System.registerNatives()V+0 java.base@21.0.3
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" (or dumping to //core.214)
#
# An error report file with more information is saved as:
# /tmp/hs_err_pid214.log
[0.024s][warning][os] Loading hsdis library failed
#
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted (core dumped)

Spent days trying to work out why it kept reporting :

ords-1        | INFO : CONN_STRING has been found in the container variables file.
ords-1        | ERROR: Cannot connect to database please validate CONN_STRING has below shape:
ords-1        |           user/password@hostname:port/service_name

Turns out it is just bad error processing in the entrypoint.sh - ANY error gets reporting suggesting invalid user/password, instead of the true error.

Wondering why this can be classified as 'latest' image when it clearly fails.

** THIS issue seems to be related to M4 ARM architecture - which probably explains why it isn't a problem for everybody. There seems to be a fix for openjdk (adding environment variable - JAVA_TOOL_OPTIONS=“-XX:UseSVE=0”), but this does not work for Oracle java.

[dario-vega]

Same as oracle/graal#11057 which is closed

[chrishoina]

@plafue I believe we, the ORDS team, has fixed this. We are in the process of assuming ownership of this ORDS project (on the /docker-images repo), so stay tuned. But I believe we added the following ENV setting to the image:

_JAVA_OPTIONS=-Xms1024M -Xmx1024M

I too have a new M4 but haven't experienced this issue. However, I have noticed in the past that increasing the memory and CPU count for my Podman machine has helped.

If you are using the compose.yaml file. I think the combination of the 23ai database + ORDS leads to the memory issue. But ONLY on Mac M4, and ONLY with GraalVM. We are updating the compose.yaml file on the Container Registry Site too. But we'll probably add it in this repo as well, as we build out the support and sample files.