-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Can't build Micronaut/Picocli project or diagnose error #7110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
GraalVM Native Image Error ReportBuild Output
Stack Tracecom.oracle.svm.core.util.VMError$HostedError: types reachable for JIT compilation must not have linkage errors
at org.graalvm.nativeimage.builder/com.oracle.svm.core.util.VMError.shouldNotReachHere(VMError.java:72)
at org.graalvm.nativeimage.builder/com.oracle.svm.core.util.VMError.guarantee(VMError.java:93)
at org.graalvm.nativeimage.builder/com.oracle.svm.graal.hosted.GraalGraphObjectReplacer.createType(GraalGraphObjectReplacer.java:318)
at org.graalvm.nativeimage.builder/com.oracle.svm.graal.hosted.GraalGraphObjectReplacer.createMethod(GraalGraphObjectReplacer.java:240)
at org.graalvm.nativeimage.builder/com.oracle.svm.graal.hosted.GraalGraphObjectReplacer.updateDataDuringAnalysis(GraalGraphObjectReplacer.java:399)
at org.graalvm.nativeimage.builder/com.oracle.svm.graal.hosted.LegacyRuntimeCompilationFeature.duringAnalysis(LegacyRuntimeCompilationFeature.java:235)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.lambda$runPointsToAnalysis$10(NativeImageGenerator.java:770)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.FeatureHandler.forEachFeature(FeatureHandler.java:86)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.lambda$runPointsToAnalysis$11(NativeImageGenerator.java:770)
at org.graalvm.nativeimage.pointsto/com.oracle.graal.pointsto.AbstractAnalysisEngine.runAnalysis(AbstractAnalysisEngine.java:179)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.runPointsToAnalysis(NativeImageGenerator.java:767)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:582)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.java:539)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:408)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:612)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.start(NativeImageGeneratorRunner.java:134)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGeneratorRunner.java:94) GraalVM Setup
GraalVM
|
@teshull native image builds other projects with micronaut v4 just fine, and we're building on micronaut v3 with the JS runtime just fine as well -- for some reason, this specific combination isn't working. (even building our graalvm integration module as a shared library works just fine -- it's this same module that triggers the issue when used as a dependency.) is there a way to work around this, or is there a chance the dev builds might already have a fix landed? could we, for instance, disable JIT to work around the linkage issue (briefly), until a fix lands? not inlining is fine, obviously, there is a performance hit; but at the moment our build is halted entirely. we can't dump the JS VM because it's inherent to the project. |
@teshull I can pass I understand this flag is experimental, but it at least yields further information, assuming the linkage error is the same. Update: here is that exception. I can attach the full error report if needed. I can try to run on the dev builds for JVM17, but we're on JVM20 and Gradle
|
cc / @remkop I don't suppose this |
Picocli does not have a type |
@remkop we are using this with Micronaut via |
could you please verify using our latest snapshot build from here: https://github.com/graalvm/graalvm-ce-dev-builds/releases If the issue still persists, could you please share a reproducer code we can use for debugging and testing? |
@oubidar-Abderrahim gradle doesn't yet support JVM21 and we're on JVM20, so we will move back to JVM17 and test from there; in terms of a reproducer, we haven't been able to capture one yet. I've been able to "prove" that the issue arises when a particular project module is on the classpath, but that's as far as I've gotten. I can't unwind or pull apart the module without a major refactor, and it isn't yet clear if the issue arises from a dependency of that module (perhaps transitively) or the code which resides in it; complicating diagnosis, the module itself builds fine as a shared library, and runs tests natively fine (via JUnit). The module's dependencies, when added to another module, build fine natively. That being said, the entire project is open source, so the bug should be reproducible via the following steps:
The module in question, which triggers the issue, is the |
@oubidar-Abderrahim alas, it looks like the same error is occurring against dev:
the error report: GraalVM Native Image Error ReportBuild Output
Stack Tracecom.oracle.svm.core.util.VMError$HostedError: Types reachable for JIT compilation must not have linkage errors
at org.graalvm.nativeimage.builder/com.oracle.svm.core.util.VMError.shouldNotReachHere(VMError.java:78)
at org.graalvm.nativeimage.builder/com.oracle.svm.core.util.VMError.guarantee(VMError.java:122)
at org.graalvm.nativeimage.builder/com.oracle.svm.graal.hosted.GraalGraphObjectReplacer.createType(GraalGraphObjectReplacer.java:330)
at org.graalvm.nativeimage.builder/com.oracle.svm.graal.hosted.GraalGraphObjectReplacer.createField(GraalGraphObjectReplacer.java:291)
at org.graalvm.nativeimage.builder/com.oracle.svm.graal.hosted.GraalGraphObjectReplacer.createAllInstanceFields(GraalGraphObjectReplacer.java:369)
at org.graalvm.nativeimage.builder/com.oracle.svm.graal.hosted.GraalGraphObjectReplacer.createType(GraalGraphObjectReplacer.java:343)
at org.graalvm.nativeimage.builder/com.oracle.svm.graal.hosted.GraalGraphObjectReplacer.createMethod(GraalGraphObjectReplacer.java:266)
at org.graalvm.nativeimage.builder/com.oracle.svm.graal.hosted.LegacyRuntimeCompilationFeature.processMethod(LegacyRuntimeCompilationFeature.java:370)
at org.graalvm.nativeimage.builder/com.oracle.svm.graal.hosted.LegacyRuntimeCompilationFeature.duringAnalysis(LegacyRuntimeCompilationFeature.java:225)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.lambda$runPointsToAnalysis$10(NativeImageGenerator.java:785)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.FeatureHandler.forEachFeature(FeatureHandler.java:90)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.lambda$runPointsToAnalysis$11(NativeImageGenerator.java:785)
at org.graalvm.nativeimage.pointsto/com.oracle.graal.pointsto.AbstractAnalysisEngine.runAnalysis(AbstractAnalysisEngine.java:181)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.runPointsToAnalysis(NativeImageGenerator.java:782)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:589)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.java:547)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:522)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:707)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.start(NativeImageGeneratorRunner.java:142)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGeneratorRunner.java:97) GraalVM Setup
GraalVM
|
Tracked internally on GR 47873 |
@oubidar-Abderrahim i'm now hitting this error on GraalVM CE dev builds, using Micronaut v3. So we can eliminate Micronaut v4 as the culprit, probably. I'm still not sure what's causing the error, it just appears for certain combinations of flags. |
Can you please provide additional details on how to reproduce this? Locally, following your instructions, (./gradlew :packages:cli:nativeCompile), I get the following error:
|
@teshull you will need to clone from the micronaut4 branch, we've frozen it where it was failing:
|
@teshull / @oubidar-Abderrahim any update on this? we're building against dev/latest and it's still breaking :/ we're worried we may need to jump back, quick, if this isn't going to make it in by the Sept release |
@teshull / @oubidar-Abderrahim with a small patch to
I can at least get some hint of what is not linking correctly:
Which shows the type:
cc / @graemerocher does this make any sense from micronaut's perspective? we are using logback, so it's reasonable that log4j would not be present, i will try building with it to see if it makes a difference; recall that |
Okay, an update, once I added the following, I can get it to build: dependencies {
// ...
implementation(mn.micronaut.websocket)
implementation(libs.slf4j.log4j.bridge) // this is `org.slf4j:log4j-over-slf4j`
implementation(libs.netty.tcnative) // this is `io.netty:netty-tcnative`
implementation("org.eclipse.jetty.npn:npn-api:8.1.2.v20120308")
implementation("org.eclipse.jetty.alpn:alpn-api:1.1.3.v20160715")
} Each dependency was resolved using that patch, since at least there is a type printed. Upon inspecting that type in IDEA, I can usually determine the transitive type that is failing to load. I would be happy to offer a PR here, albeit for a one line change; the error could be formatted better, for sure, than my patch, but at the very least having something to grab on to with this particular error was very helpful in the diagnosis process. @graemerocher we are using Netty, not Jetty, and a bunch of BOMs are pulled into our Micronaut v4 build if I add these deps; it seems like I'm not sure why those particular dependencies weren't making it into the build. I've never had to add Some other context for this issue, as relates to Micronaut:
|
- fix: missing `log4j` classes, via `slf4j` bridge - fix: allow conditional language inclusion in `cli` build - fix: drop JRT flag to `native-image` - fix: swap to `NONE` runtime for Micronaut - fix: missing `initialize-at-build-time` netty types - fix: missing Netty, NPN, ALPN dependencies - chore: ability to dynamically load/detect languages in cli Fixes and closes #394. Relates-To: oracle/graal#7110 Relates-To: micronaut-projects/micronaut-core#9664 Relates-To: #394 Signed-off-by: Sam Gammon <[email protected]>
- fix: missing `log4j` classes, via `slf4j` bridge - fix: allow conditional language inclusion in `cli` build - fix: drop JRT flag to `native-image` - fix: swap to `NONE` runtime for Micronaut - fix: missing `initialize-at-build-time` netty types - fix: missing Netty, NPN, ALPN dependencies - chore: ability to dynamically load/detect languages in cli Fixes and closes #394. Relates-To: oracle/graal#7110 Relates-To: micronaut-projects/micronaut-core#9664 Relates-To: #394 Signed-off-by: Sam Gammon <[email protected]>
Hi @sgammon, sorry for the delay. I'm glad you were able to resolve your issue. In the end it looks like it was an configuration issue, correct? I'll add a message to the GraalObjectReplacer. In general, there is room for improvement in returning more informative/actionable error messages |
@teshull Thank you and no worries. I think the real "bug" here is that we couldn't diagnose this, yeah. The missing dependencies may be informative for the Micronaut team, maybe they are intended to be there. Stringifying the type that experienced the linkage issue isn't the nicest error, it's true, but at the very least it gave us a hint which helped us find each "missing" type. A fix would be awesome to get in to |
@teshull cc / @oubidar-Abderrahim congrats on the release! 🥳 this looks fixed, so I'll close, especially since there is an internal bug tracking the issue. Thank you for your help and hard work! |
We are building an open source project which relies on GraalVM as the execution engine. As part of this project, we have a CLI target, which uses the main
graalvm
module (all Gradle modules). Upon upgrading to Micronaut v4, we've encountered this "JIT compilation must not have linkage errors" exception and cannot proceed any further.Things we've tried
Building a pure hello-world sample with the
graalvm
module listed as a dependency is sufficient to cause the issue. Separately, we are building fine with Micronanut 4 and GraalVM (in other projects), so it's unclear why it's failing, and the exception stacktrace offers no hints about how to diagnose.The text was updated successfully, but these errors were encountered: