-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Fatal error: com.oracle.svm.core.util.VMError$HostedError: should not reach here #5558
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
@oldshensheep From a quick look at |
I successfully built it on Linux. But startup failed.
|
Hi, thank you for reaching out, could you please provide some details
|
|
Please use the tracing agent to collect Metadata config before building your image, you can find more about it here: https://www.graalvm.org/22.3/reference-manual/native-image/metadata/AutomaticMetadataCollection/ |
Any updates? |
@oldshensheep It looks like you're using sqlite with hibernate and spring data JPA? I'm fairly certain that this is a problem the mechanism that org.sqlite is using to load its native library is not being exercised at build time. I've seen a couple of different ways that people have hacked around this, including adding the whole java.lang.Classloader to JNI-config, which feels like it's not the right path to take, and spring boot cannot build a native image with that set globally. Most working demos of org.xerial:sqlite-jdbc that I've seen have Solving this will probably involve finding the right way to initialize that database connection at build time, so that graalVM can prepare everything necessary for it at runtime. The right way to do this probably involves either graalvm hints, or Spring annotation that will generate them for us. I had hoped that opening a connection in the main before running the Spring Boot application would help, but all that does is force the NPE immediately:
results in
before spring even starts up |
Here's the only working example I've seen of this specific sqlite library being used in a graalVM native image: https://github.com/ericdallo/sqlite-graalvm-sample |
I poked at this a bit more. To summarize, Spring Boot is not capable of initializing all classes at build time, or of adding the classloader to JNI config globally, but when I ran the tracing agent on my application and then applied the jni-config.json that it detected, then my application started up, and yours should be able to also. This seems to be a shortcoming of https://github.com/xerial/sqlite-jdbc that we should fix. It's only loadable in graalvm when doing build-time class initialization. Here's the jni-config.json that my tracing agent recommended, for a spring boot application using spring data JPA & the same sqilte jdbc driver that yours is: Edit: It's one of these that is specifcally doing the trick. Interesting
|
@oldshensheep and Graal maintainers, I just wanted to conclude my own findings when I encountered this same problem with org.sqlite.sqlite-jdbc This isn't a graal problem, it's that sqlite-jdbc calls Throwable from the native side of JNI, but does not provide that as a JNI hint. This problem can be fixed by adding
to jni-config.json |
@pettyalex Thank you for providing the solution. |
@oubidar-Abderrahim |
Even though my program starts properly, some of the APIs don't work properly, so there should still be a problem with my configuration file. I am working on it. |
I changed my code. It works fine on Linux Edit after 12 hours: Edit Edit Show startup log
|
To summarize the current state. |
So all the problems are solved. But there is one last problem, I need to figure out why compiling on my Windows computer will give me |
have this also, no spring involved. It does generate exe on windows, but compiler exits with 'should not reach here'... |
It's good that the issue is fixed for Linux, if you have a new error, please open another Github ticket for it and we'll take a look into it. Thank you |
same bug in graalvm, pls re-open the ticket |
This comment was marked as outdated.
This comment was marked as outdated.
@oeresundsgruppen @oubidar-Abderrahim If you have this problem, you need doing this
the
THE SOLUTION: Edit: I found this pull request #5881 Set up build environments for Windows users. |
I upgraded to latest vs2022 and the problem went away... |
Uh oh!
There was an error while loading. Please reload this page.
Describe the issue
Fatal error: com.oracle.svm.core.util.VMError$HostedError: should not reach here
Steps to reproduce the issue
Describe GraalVM and your environment:
More details
Build optionl --enable-preview --verbose --native-image-info
Using VirtualThread
Log There!
build.log
SOLVED #5558 (comment)
The text was updated successfully, but these errors were encountered: