Gem.install caused a BootstrapMethodError #7120
Comments
|
Sorry to not jump on this one right away. Looking at the trace, this seems like it relates to OSGI. The final error at the bottom (thanks for including both sets of traces!) mentions a classloader mismatch that prevents a method from linking properly. Unfortunately I know almost nothing about OSGI. It might be easiest if you pushed a small repository that reproduced this issue, so I can just build and run it and get the same result. |
|
I have a similar (or same) error outside OSGi, in a Maven build using asciidoctor-maven-plugin. Unfortunately, I currently cannot provide more information as I am still investigating it. But just as a hint, the conculusion that the issue is OSGi related might prove wrong... |
|
My apologies for not having been able to provide the steps to reproduce this issue. It is encountered in a rather convoluted setup and I haven't been able to create a simple/small simulated environment to trigger the same error. |
|
I can now however provide some other clues. The behaviour is not the same with different Java implementations. I have the issue when using JDK or OpenJDK 8, 11, 12, and 13. With JDK or OpenJDK 14, 15, 16, 17, 18, or 19EA the issue does not occur. It also does not occur with IBM J9 Java 11. (All runs done with most recent release of each version.) @jimtng can you reproduce my findings regarnding Java-Versions? |
|
Still another finding, in case it might help. The issue did not exist with JRuby version 9.2.20.1 and came into existence with 9.3.0.0, irregardles of the JDK version used. |
|
@domagojcc For some reasons I couldn't build against jruby 9.2.x any more. However I did try using Zulu jre 17 and the problem does not occur like you said. Thanks for this discovery! Previously I was using java 11 where the problem occurred. I'm happy to consider this as the solution since I believe we're going to move to java 17 soon. @headius / @domagojcc should I keep this issue open? |
|
We sometimes get a similar issue with JRuby 9.3.3.0 and 9.3.4.0 when we load our application as a Jira plugin which runs as an OSGi plugin. We do not get it after a fresh start but after uninstalling and reinstalling the plugin: As I see the failing line at extensions = if /\A#{PREFIX}/ =~ file.readline.chomp
$'.split "\0"
else
StubLine::NO_EXTENSIONS
endAny ideas on which method call here could cause this |
|
@rsim did you get |
|
@jimtng Sometimes I see a similar error: It seems that one of the causes is that after I uninstall this OSGi plugin there are still many JRuby objects remaining in the memory and I have not yet debugged what keeps the references to them. And then during the next installation of the plugin somehow the old existing JRuby java classes are found which causes this error about different class loader. |
|
I'm looking in JRuby source handle = MethodHandles.publicLookup().findStatic(Helpers.class, "constructRubyStringArray", MethodType.methodType(RubyString[].class, CodegenUtils.params(RubyString.class, size)));and I suspect that when there are several OSGi plugins with several @headius I found out that the usage of |
|
Found a similar problem mentioned on Twitter https://twitter.com/felix_b/status/1321088287285645312 |
|
I managed to create a workaround for this problem by patching if (size > 10)to if (size > 0)which as a result avoids the usage of But still it would be better to make a correct solution which would find the correct methods from the Helpers class that is loaded with the current classloader. |
|
Ok thank you for the exploration and new evidence. I wish I could reproduce this. So far it still seems like it is not exactly our bug. There's no reason I can think of that the call to findStatic from and to the same class would ever produce an error or see across classloaders. I expect it is either a JDK or an OSGi bug. However...we still need to make it work. One half-measure would be to detect that we are on a JDK that does this collect operation fast and skip the custom collect logic. That would work for newer JDKs to avoid this issue, and perhaps for older JDKs once patched. It requires us to test all major versions and see if the performance issue is still present. An alternative option that might help would be to acquire and cache these handles at boot time, so they are only acquired once (presumably all within one classloader) and future collects do not try to reacquire (possibly across classloaders boundaries). A third option would be to convert these collector methods into lambdas and bind those to the method handle chain rather than direct handles to the collector methods themselves. This would ensure we are only binding to live objects provided by the JDK's lambda bootstrapping. Any further issues at that point would implicate the JDK. I can try to come up with a patch for this tomorrow while I am in transit, but if someone can experiment with these ideas it would save some time. |
|
@rsim, are you able to create a reproducible example? |
|
@headius Thanks for taking a look at this during your vacation :) I did further experiments and replaced in handle = MethodHandles.publicLookup().findStatic(...)with handle = MethodHandles.lookup().findStatic(...)and this solved the problem as well. After repeated installations / uninstallations of OSGi plugins with JRuby runtimes inside them, there were no errors with calling found methods with As I see
and
So probably As I see currently in other places sometimes In our case, we need this to work on both JDK 8 and 11 (and in the future on 17). So it would be good to use a generic solution that works correctly on all JDKs. |
@headius, I tried the changes suggested by @rsim as quoted above and I can confirm also that the problem is solved by these changes. If this is an accepted solution, @rsim would you be able to create a PR? I'll make one if you're all busy. |
|
I did not see this issue reported to OpenJDK so I opened an issue here: https://bugs.openjdk.org/browse/JDK-8291922 We will go forward with the fix proposed by @rsim and PRed by @jimtng in #7271, since it is low-impact. |
|
Does anyone have a simple way to reproduce this? Apparently there were many changes in this area for JDK 14 and the OpenJDK folks responsible are looking for a good reproduction so they can track down what the actual fix was. |
|
Ping @rsim @jimtng @domagojcc for help coming up with a reproduction. |
|
We experienced this problem when using Felix-based OSGi implementation in Atlassian Jira plugins. It will take us some while to create a smaller reproducible example for this issue. |
Environment Information
Provide at least:
I'm using JRuby through org.jruby.embed.jsr223.JRubyEngineFactory, inside an osgi bundle
Expected Behavior
Calling
Gem.install(any_valid_installable_gem)should install the gem if it isn't already installed, or proceed without error.Actual Behavior
Gem.install caused the following error:
Error type 1
Error type 2
Under certain situations it sometimes throw this error:
The text was updated successfully, but these errors were encountered: