Closed nloke closed 1 year ago
/cc @Karm (mandrel), @Sgitario (kubernetes), @evanchooly (kotlin), @galderz (mandrel), @geoand (kotlin,kubernetes), @iocanel (kubernetes), @zakkak (mandrel)
@nloke thanks for reporting this. It looks like a Mandrel / GraalVM issue. Could you please provide some more info?
What container runtime (docker, podman, etc.) are you using and in what mode (i.e., rootless or rootfull)?
Does the issue reproduce with a simple Hello World?
Do I understand correctly that you are building a Linux binary on MacOS using the default Quarkus native builder image (i.e. you don't set quarkus.native.builder-image
)?
I have not reproduced the issue yet but I see that it's triggered by a PrivilegedActionException
, so a possible workaround would be to try running the container runtime in rootfull mode.
@zakkak I don't think this is a bug but I think a better logging to pinpoint what caused the error will be of great help.
We got lucky as we stumbled upon RuntimeClassInitialization (GraalVM SDK Java API Reference)
Based on that reference SDK, we figured the code below caused the issue
private static final JsonSchemaOptions JSON_SCHEMA_OPTIONS = new JsonSchemaOptions().setDraft(Draft.DRAFT201909)
Changing it to
private final JsonSchemaOptions JSON_SCHEMA_OPTIONS = new JsonSchemaOptions().setDraft(Draft.DRAFT201909)
solved the build error.
As I mentioned above, if the build logs can report this, it would have helped a lot. Luckily our code base is small and we area able to skim through all the classes we have to try to figure what is the potential issue.
@nloke it still looks like a bug to me. The error says that the "Unsupported field jdk.internal.loader.NativeLibraries.loadedLibraryNames is reachable" and looking at the trace we see that it's reachable through GraalVM's code. So no matter if you managed to work around this by preventing JSON_SCHEMA_OPTIONS
to be initialized at build-time, GraalVM should ensure it never needs access to an unsupported field.
As I mentioned above, if the build logs can report this, it would have helped a lot.
The build logs could perhaps report this (an issue with build time initialization of JsonSchemaOptions
probably) if GraalVM didn't exit because of the unsupported field access.
I will try to replicate the issue using the code segment that you changed to work around the issue and see why that happens. In the meantime I would appreciate it if you could answer my questions in https://github.com/quarkusio/quarkus/issues/32009#issuecomment-1479174579. Thanks
What container runtime (docker, podman, etc.) are you using and in what mode (i.e., rootless or rootfull)?
I am using Colima with docker as runtime and another colleague of mine is using docker-desktop. I am unsure if I am rootfull or rootless since I am using the default docker runtime from Colima instead of Containerd where for that I know it is rootless by default. I was not able to quickly find the default value for Colima with docker runtime to be rootfull or rootless
Does the issue reproduce with a simple Hello World?
We have not tried creating a hello world with the static code I mentioned above
Do I understand correctly that you are building a Linux binary on MacOS using the default Quarkus native builder image (i.e. you don't set quarkus.native.builder-image)?
Yes we are trying to build the docker image with the command ./mvnw package -Pnative -Dquarkus.native.container-build=true -Dquarkus.native.container-runtime=docker -DskipTests from our macOS terminal
@nloke I suspect that this issue (and the reason you could not figure out what was wrong) is related to https://github.com/oracle/graal/issues/6368
Based on that reference SDK, we figured the code below caused the issue
Can you please explain what was the issue with this code? Did it fail to run during static initialization?
@zakkak We are not 100% sure but we just tried it out by removing the static for the variables we had in the code and made it none static and the build just pass without the failure step in the logs I shared in the first comment.
We do not have more info other than the build log exception that we shared.
I tried to reproduce this with colima (and docker) as well as with podman (both rootless and rootful) without success so I am closing it in luck of reproducer.
Describe the bug
I am facing an issue when I am doing a native build and I am not sure where to proceed to try to resolve the issue as no where in the stack trace indicates what I have done wrong in my code.
If someone can help give some pointers to help resolve this issue will be greatly appreciated i.e what compilation logs to provide and etc.
I am currently using quarkus 2.16.4.Final
This is my dependency tree
Expected behavior
Native build to work or at least point to me where could be the error on my code that caused this
Actual behavior
Native build failed with above exception and does not provide much info if it is my code that is wrong and causes this
How to Reproduce?
No response
Output of
uname -a
orver
Darwin MacBook-Pro-PC.local 21.4.0 Darwin Kernel Version 21.4.0: Mon Feb 21 20:34:37 PST 2022; root:xnu-8020.101.4~2/RELEASE_X86_64 x86_64
Output of
java -version
openjdk version "19.0.1" 2022-10-18 OpenJDK Runtime Environment Homebrew (build 19.0.1) OpenJDK 64-Bit Server VM Homebrew (build 19.0.1, mixed mode, sharing)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.16.4.FINAL
Build tool (ie. output of
mvnw --version
orgradlew --version
)Maven home: /usr/local/Cellar/maven/3.8.6/libexec Java version: 19.0.1, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk/19.0.1/libexec/openjdk.jdk/Contents/Home Default locale: en_CA, platform encoding: UTF-8 OS name: "mac os x", version: "12.3", arch: "x86_64", family: "mac"
Additional information
No response