Fatal error: com.oracle.svm.core.util.VMError$HostedError: com.oracle.svm.core.util.VMError$HostedError: ... has no code address offset set

[borkdude]

I'm getting this error when compiling a native binary on Mac on CircleCI.

Fatal error: com.oracle.svm.core.util.VMError$HostedError: com.oracle.svm.core.util.VMError$HostedError: sci.impl.fns$eval_fn.invokeStatic(Object, Object, Object): has no code address offset set.

The project branch: https://github.com/borkdude/babashka/blob/10c7d705cd8c33f2db8a26d0499f006c1a029360
and build script:
https://github.com/borkdude/babashka/blob/10c7d705cd8c33f2db8a26d0499f006c1a029360/script/compile#L1
The failing build on CircleCI: https://circleci.com/gh/borkdude/babashka/367

This error is coming from a library which I'm also testing separately on CircleCI with Mac and there it works fine: https://circleci.com/gh/borkdude/sci/114.

However, I don't get this error locally on my Mac. Note that the same project succeeds with Linux on CircleCI.

[borkdude]

This problem is solved when I include the source files of the sci library in the babashka project and then AOT them over there. But I'm still not sure why it worked flawlessly for linux and not for CircleCI+Mac.

[borkdude]

Running into this problem again with another project: https://app.circleci.com/pipelines/github/borkdude/clj-kondo/3169/workflows/f3ad112c-6b45-4a95-993d-3b0aad09bf91/jobs/12157

[borkdude]

Bumping Xcode in the CircleCI environment seemed to help: 9 -> 12.

https://app.circleci.com/pipelines/github/borkdude/clj-kondo/3170/workflows/5cf9e375-c06a-4c83-b1df-f0e158549402/jobs/12165

[FieryCod]

This happens not only for sci. It looks like a random error which vanishes after few attempts.

Fatal error:com.oracle.svm.core.util.VMError$HostedError: com.oracle.svm.core.util.VMError$HostedError: java_time.amount$days.invokeStatic(Object): has no code address offset set.
	at com.oracle.svm.core.util.VMError.shouldNotReachHere(VMError.java:72)
	at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:694)
	at com.oracle.svm.hosted.NativeImageGenerator.lambda$run$2(NativeImageGenerator.java:495)
	at java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1386)
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
	at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:175)
Caused by: com.oracle.svm.core.util.VMError$HostedError: java_time.amount$days.invokeStatic(Object): has no code address offset set.
	at com.oracle.svm.core.util.VMError.shouldNotReachHere(VMError.java:68)
	at com.oracle.svm.hosted.meta.HostedMethod.getCodeAddressOffset(HostedMethod.java:149)
	at com.oracle.svm.hosted.image.LIRNativeImageCodeCache.patchMethods(LIRNativeImageCodeCache.java:186)
	at com.oracle.svm.hosted.image.NativeImage$NativeTextSectionImpl.writeTextSection(NativeImage.java:945)
	at com.oracle.svm.hosted.image.NativeImage.build(NativeImage.java:439)
	at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:683)
	... 6 more
Error: Image build request failed with exit status 1
com.oracle.svm.driver.NativeImage$NativeImageError: Image build request failed with exit status 1
	at com.oracle.svm.driver.NativeImage.showError(NativeImage.java:1772)
	at com.oracle.svm.driver.NativeImage.build(NativeImage.java:1519)
	at com.oracle.svm.driver.NativeImage.performBuild(NativeImage.java:1480)
	at com.oracle.svm.driver.NativeImage.main(NativeImage.java:1467)

[borkdude]

@FieryCod Are you by any chance using leiningen and :aot :all?

[FieryCod]

@borkdude Nope. This a report from one of the users of holy-lambda. I have transitioned from using leiningen to depstar.
Here is how holy-lambda compiles the user project.

What I can say is after switching to depstar I'm receiving those has no code address offset set frequently. I have never spot such issue when using leiningen, but maybe it's because I was using GraalVM 19.3.0 before.

[borkdude]

If you are using depstar, there is a similar compilation happening with :aot true. Try not use :aot true but :aot [main-ns] or :compile-ns main-ns where main-ns is the namespace with your -main function.

[FieryCod]

@olpaw @cstancu Minimal reproduction here: https://github.com/FieryCod/graalvm-1613-repro

[borkdude]

@FieryCod If I simplify the compilation to use "just Clojure", like this, it works:

SHELL := /bin/bash
PWD=$$(pwd)
USER_GID=$$(id -u):$$(id -g)

clean:
	@rm -Rf .cpcache target output output.build_artifacts.txt

compile:
	rm -rf classes
	mkdir -p classes
	clojure -M -e "(compile 'com.company.example.core)"

graalvm:
	$(GRAALVM_HOME)/bin/native-image -cp $(shell clojure -Spath):classes \
		 -H:+AllowIncompleteClasspath \
		 --report-unsupported-elements-at-runtime \
		 --no-fallback \
		 --verbose \
		 --enable-url-protocols=http,https \
		 --no-server \
		 --initialize-at-build-time \
                 com.company.example.core

[borkdude]

Another data point. When I compile using

clojure -J-Dclojure.compiler.direct-linking=true -J-Dclojure.spec.skip-macros=true -M -e "(compile 'com.company.example.core)" 

I get the issue again.

Removing -J-Dclojure.spec.skip-macros=true did not change that, so it seems to be related to direct linking.

[borkdude]

The way the java.time.amount$days function is defined is pretty non-standard:

https://github.com/dm3/clojure.java-time/blob/351fb243359635f4d1939e8112c3046d5edb7af1/src/java_time/amount.clj#L73-L84

[borkdude]

It looks like this issue was caused by compiling the same namespace multiple times. Just don't do that and this error should not occur.