Error: No instances are allowed in the image heap for a class that is initialized or reinitialized at image runtime: javax.net.ssl.SSLContext #1074
Comments
|
Compilation is successful if I remove http-server libraries which is making use of java.net.*, through the use of the http-kit library. This was working in previous releases without issues, so it isn't clear what has changed. |
|
FWIW, I can reproduce this using 19.0.0. I'm using this with Clojure, so I already have |
|
The problem comes from We should trace where this happens and fix support for |
|
Yep, it's definitely true that there are image heap instances of SSLContext. For example, One confusing tidbit is that the suggested remediation from the error is Does "fix support for j.n.s.SSLContext" here mean changing something about GraalVM? Is there any amount of minimal reproducer I can help make that would be helpful to you? Just in case, I created https://github.com/lvh/cljurl-graalvm-demo, created an uberjar with |
|
Hmm, we need to see how this instance ended up in the heap. The problem comes from: First, Now we need to find which initializer added this class to the heap and we need to delay it to runtime: Do you have an idea where this class could of been added? Can you attach a debugger to clojure to see where is this instance created? If yes, all we need is a breakpoint in The error message is actually correct as the policy for the given class is |
|
@vjovanov Sorry, I may be adding to the confusion here. I'm speaking about my reproducer, which has I can try to figure out if the instance is created, but is there a way for me to confirm that the given class is actually |
|
It is most likely ‘RERUN’ as it is set so in ‘native-image’. There is a flag ‘-H:+PrintClassInitialization’ that will give you all the details and reasons. You can also look at the new documentation that explains it: https://github.com/oracle/graal/blob/master/substratevm/CLASS-INITIALIZATION.md |
|
Yep; I read that doc and I'm running with I tried picking some classes that look promising from the traces: ... but now I just get the same errors at different I'll keep banging at it to see if I can find which class is introducing the issue :) I guess I'm more likely to find the culprit from the "Call path from entry point"? (Functions in Clojure map to classes on the JVM so hopefully we'll have fine granularity here.) |
|
Yes, in combination with object path. Note that the call path is just the shortest path and not necessarily the one that causes the issue. The error messages are misleading here. Since you already explicitly marked classes as |
|
Gotcha, makes sense. So: find classes introducing objects in the image, make them initialize at run-time, rinse, repeat. I might just parse the output and try to come up with those locations automatically. Also, since you mention that's just a shortest path, is there a way for native-image to dump all the paths? I'm happy to burn hours of CPU time on this and less happy to burn hours of human time on this :-) Any idea if/when/where I should be seeing output from |
|
Figured it out: unfortunately the printed classes only happen after analysis, and the error above happens before analysis. Also for any Clojure folks reading: it's a lot easier to get https://github.com/martinklepsch/clj-http-lite/ working than clj-http. The former relies on the JVM builtin URL openers, whereas the latter is a pretty involved library using the Apache HTTP Client. There's some reduction in functionality but odds are you don't really care about that. |
|
Yes, I am working on error reporting now: It will print all of the issues it finds on one go so repeat happens less. Also, I will try to print available info when the error occurs so that it is easier to get things right. Unfortunately, error reporting requires using java agents to track initialization and that is hard to integrate with the rest. The solution will be out soon. Thanks for the valuable feedback, it will make things better. |
|
Hello, I've come across (presumably) the same issue with I've created the repo with the code to reproduce the issue: https://github.com/ilya-murzinov/weblfux-graalvm Can someone please point me to some simple workaround? |
|
|
@lvh I've tried but got the following error: |
|
@ilya-murzinov that looks like a similar problem with netty, which I haven't tried to get working either. Note, I suggested just |
|
This is expected behavior: we can not specify two different policies for the same class ( |
Using a lighter HTTP client library makes it possible to use GraalVM native image with the no fallback mode. Executable is now faster: time ./hubstats.core ... ./hubstats.core 0.00s user 0.00s system 60% cpu 0.008 total instead of: time ./hubstats.core ... ./hubstats.core 5.34s user 0.28s system 234% cpu 2.398 total See oracle/graal#1074 (comment)
Using a lighter HTTP client library makes it possible to use GraalVM native image with the no fallback mode. Executable is now faster: time ./hubstats.core ... ./hubstats.core 0.00s user 0.00s system 60% cpu 0.008 total instead of: time ./hubstats.core ... ./hubstats.core 5.34s user 0.28s system 234% cpu 2.398 total See oracle/graal#1074 (comment)
@ivh I think you meant |
|
Is this still a valid issue? If yes, please reopen. |
Using RC13, I wonder if it's related to #712
Full command from https://github.com/benzap/eden
build-native.sh, Line 28
This was definitely compiling when I was first messing around with it, so it's unclear why it suddenly decided to stop working. I'm wondering if the error output is a misdirection?
Here is the error output:
If you would like to reproduce, it will require installing leiningen, and setting GRAAL_HOME to the graalvm folder
GRAAL_HOME=/path/to/graal sh build-native.shThank you for your time,
Ben
The text was updated successfully, but these errors were encountered: