Quarkus: Error while creating the native imgae on mac os

[shahparthiv]

I am running the below command

./mvnw package -Pnative -Dquarkus.native.container-build=true

I am getting following error

[ERROR] Failed to execute goal io.quarkus:quarkus-maven-plugin:1.3.1.Final:build (default) on project my-artifactId: Failed to build quarkus application: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
[ERROR]     [error]: Build step io.quarkus.deployment.pkg.steps.NativeImageBuildStep#build threw an exception: java.lang.RuntimeException: Failed to build native image
[ERROR]     at io.quarkus.deployment.pkg.steps.NativeImageBuildStep.build(NativeImageBuildStep.java:353)
[ERROR]     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR]     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR]     at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR]     at java.base/java.lang.reflect.Method.invoke(Method.java:566)
[ERROR]     at io.quarkus.deployment.ExtensionLoader$2.execute(ExtensionLoader.java:938)
[ERROR]     at io.quarkus.builder.BuildContext.run(BuildContext.java:273)
[ERROR]     at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
[ERROR]     at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:2027)
[ERROR]     at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1551)
[ERROR]     at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1442)
[ERROR]     at java.base/java.lang.Thread.run(Thread.java:834)
[ERROR]     at org.jboss.threads.JBossThread.run(JBossThread.java:479)
[ERROR] Caused by: java.lang.RuntimeException: Image generation failed. Exit code: 125
[ERROR]     at io.quarkus.deployment.pkg.steps.NativeImageBuildStep.imageGenerationFailed(NativeImageBuildStep.java:369)
[ERROR]     at io.quarkus.deployment.pkg.steps.NativeImageBuildStep.build(NativeImageBuildStep.java:339)
[ERROR]     ... 12 more

Environment (please complete the following information):

• Output of uname -a or ver: Darwin Parthiv.local 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53 PST 2018; root:xnu-4903.241.1~1/RELEASE_X86_64 x86_64
• Output of java -version:

openjdk version "11.0.6" 2020-01-14
OpenJDK Runtime Environment GraalVM CE 20.0.0 (build 11.0.6+9-jvmci-20.0-b02)
OpenJDK 64-Bit Server VM GraalVM CE 20.0.0 (build 11.0.6+9-jvmci-20.0-b02, mixed mode, sharing)

• Quarkus version or git rev: 1.3.1
• Build tool (ie. output of mvnw --version or gradlew --version): Apache Maven 3.6.3

[geoand]

Is there any more information in the output?

Perhaps if you add -X?

[shahparthiv]

I have ran the command using -X.
Please check the attached log file.
logs.log

[geoand]

Hm... I see [ERROR] [io.quarkus.deployment.pkg.steps.NativeImageBuildStep] Unable to get GraalVM version from the native-image binary. in the logs.

Can you please try and execute the following command:

docker run --rm quay.io/quarkus/ubi-quarkus-native-image:19.3.1-java11 --version

?

[shahparthiv]

hey I ran the given command and output is: GraalVM Version 19.3.1 CE

In my bashrc I have set the path as below:
export GRAALVM_HOME=/Library/Java/JavaVirtualMachines/graalvm-ce-java11-20.0.0/Contents/Home

and in path $GRAALVM_HOME/bin

The command you gave is returning 19.3.1 and I have installed 20.0.0
please let me know If I configure something wrong.

[shahparthiv]

@geoand, @Sanne, As the attached issue is merged.
I need to just run the command or I need to upgrade something?

[shahparthiv]

any update?

[Sanne]

sorry the merged issue #8429 is unrelated. I also don't have a mac myself, I'll let others on the team investigate this issue. @geoand is this on your plate?

[geoand]

I have never even used a Mac, so it will be difficult for me take it :)

[Sanne]

I have never even used a Mac, so it will be difficult for me take it :)

lol me neither. Linux since 20 years! Ok let's ask to our other teammates then.

[geoand]

@shahparthiv I don't supose anything changed with version 1.4.0.CR1 of Quarkus (you've have to use quarkus-bom instead of quarkus-platform to test it)

[maxandersen]

do you have a reproducer proejct ? then I can try reproduce on my mac.

[ebullient]

Native image generation works ok for me on 1.3.2-Final on MacOS. I will try with latest quarkus/master, too..

What consistently fails is trying to build that image with -Dquarkus.native.container-build=true (which is what is also attempted above). For me, the build hangs for a LONG TIME, and then reports OutOfMemory, and dies.

Happy to run a screenshare so you guys can poke around..

[geoand]

@ebullient mind adding -Dquarkus.native.native-image-xmx=5g and trying again?

[ebullient]

Relaying here (@geoand and I will keep tossing things back and forth in Zulip), adding the above attribute lands me with the pretty error message the OP reported. ;)

[ebullient]

Ok. The pretty error message isn't coming out because the Image generation step/process is exiting with RC=1 (rather than the pretty 137 that is emitted somewhere):

Caused by: java.lang.RuntimeException: Image generation failed. Exit code: 1
    at io.quarkus.deployment.pkg.steps.NativeImageBuildStep.imageGenerationFailed (NativeImageBuildStep.java:369)
    at io.quarkus.deployment.pkg.steps.NativeImageBuildStep.build (NativeImageBuildStep.java:339)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at io.quarkus.deployment.ExtensionLoader$2.execute (ExtensionLoader.java:938)
    at io.quarkus.builder.BuildContext.run (BuildContext.java:273)
    at org.jboss.threads.ContextClassLoaderSavingRunnable.run (ContextClassLoaderSavingRunnable.java:35)
    at org.jboss.threads.EnhancedQueueExecutor.safeRun (EnhancedQueueExecutor.java:2027)
    at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask (EnhancedQueueExecutor.java:1551)
    at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run (EnhancedQueueExecutor.java:1442)
    at java.lang.Thread.run (Thread.java:834)
    at org.jboss.threads.JBossThread.run (JBossThread.java:479)

What I still can't understand is _why_ it is totally running out of memory. I have tried all kinds of numbers other than 5g that are bigger, and none of them seem to change anything. I would be scared for my app if creating native binaries didn't work just fine for macos and linux when not building using the container.

[geoand]

@ebullient I am not sure which scenario your observation applies to.

[ebullient]

I can compile a native image on mac OS without an issue.
If I want to build a containerized native image, that requires using a build container.
Setting -Dquarkus.native.native-image-xmx=5g gives me a slightly faster fail than before, but it still fails. It doesn't seem like changing that specific number helps. I don't think infinite RAM is required, because my mac doesn't tip over when building the image w/o docker.

So, do we know what is chewing memory? Is that value the right value to try increasing, or is there something else that could also be required?

[geoand]

On Mac (and Windows) when using docker, one also has to set the max memory the VM (which is used implicitly) can have.
So you also might have to increase that value.

On Linux there is no such VM and docker can access all memory.

[ebullient]

I understand that. What I don't understand is how I am supposed to increase that value, as any combination of numbers I tried (which all seemed reasonable) had no effect.

[geoand]

The docker VM should have as much memory as possible, that's for sure.

As for the JVM that runs the native image build, that's trickier since there are a lot of ergonomics in play... Might I suggest using Xmx of a couple gigabyte less than the VM memory.