-
-
Notifications
You must be signed in to change notification settings - Fork 925
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
NullPointerExeption in org.jruby.RubyBasicObject.yieldUnder #4037
Comments
Small note: The whole project / app runs without problems when using: ruby 1.7.23 (1.9.3p551) 2015-11-24 f496dd5 on Java HotSpot(TM) 64-Bit Server VM 1.8.0_101-b13 +jit [linux-amd64] or jruby 9.0.5.0 (2.2.3) 2016-01-26 7bee00d Java HotSpot(TM) 64-Bit Server VM 25.101-b13 on 1.8.0_101-b13 +jit [linux-amd64] |
seems that the block's binding is |
I tried out the other JRuby versions in between and can say that the regression was introduced with version 9.1.0.0. |
@obfuscoder any chance you can bisect this for us? I know that is a big task since you need to recompile jruby several times but the commit in question might narrow this down as fast as you making a reproduction (repros using any Rails library tends to be a pretty big repro). |
I'll try and bisect the issue today. |
Ok I am having trouble even when trying to compile the first in-between-version of the bisect 28a9f53. First of all, there are dependencies on SNAPSHOT versions of components outside of the jruby repository which themselves have SNAPSHOT dependencies. This makes it impossible for me to determin which of the commits of those dependencies are compatible and shall be used. Those components are jffi, jnr-constants, jnr-ffi, jnr-posix and joni. I tried to download and compile those snapshot versions but could only guess at which of the checkouts I should use. I generally used the last commit before the version switch to the actual release version. After compiling all those SNAPSHOT versions I get a compilation failure when compiling jruby with ./mvnw:
So far I'm pretty stuck. Neither -X nr -e reveals any more details apart from this stack trace:
|
As I mentioned it is near to impossible for me to do the bisecting. Another approach would be to extract some kind of a reproduction case rails app based on our app. I invested a couple of hours in this, but this is also quite an effort. We have some Java interop and custom gems. I'm not allowed to share this code. Could you figure out the issue without me bisecting this or providing a sample app? |
that's unfortunate ... you could ignore all of the commits that have "truffle" in them as they're not related. again from the provided stack there's some gem code and a bit of active-record (rails stack) ending up in an |
Ignoring truffle commits does not help much. First commit without truffle when bisecting is this one: 6761527 Still getting compile errors JDK 8 crashes with:
What Java version are you using for compilation? |
Using Oracle 7 JDK results in a SIGSEGV as well. Trying OpenJDK... |
SIGSEGV also with OpenJDK. I have a 64bit system. Might this be the problem? Any Java options I should set or do you have some kind of a virtual machine (e.g.. docker image) which I could use for this? |
I am stuck here and would love to get some help. Be aware that at the moment we cannot use JRuby 9.x at all. Version 9.0.5.0 is too slow (our specs take 300% more time compared to 1.7.23) and we get OutOfMemory exceptions (memory consumption running specs is +200% compared to 1.7.23). So we are pretty much bound to Version 1.7.23. As more and more gems start to require Ruby 2.x we don't get security fixes for the older versions anymore. If we can't use JRuby we need to change our whole architecture by trying to go to MRI - replacing our Java parts with micro services. I honestly hope that we find a solution which allows us to continue using JRuby. |
@obfuscoder not sure the issue is identified without a reproduction case, did you gave up on that? the other option would be to get some (private) help (over your code base) extracting or identifying the problem ... if you're into that of course. |
@kares As I stated I want to try and bisect JRuby, but I am yet unable to compile any version and asked for help on this one. |
no extra JAVA options need to be set, if you check .travis.yml you shall see that it compiles fine under Java 7 as well as 8 (would recommend using Oracle JDK). there might be some SNAPSHOT dependencies in pom.xml that are no longer there - this is something you might need to deal with. I have no idea why you're stuck (using the above details) - maybe a commit broke compilation thus try a parent. it's a multi module |
@obfuscoder if you are using the filesystem installation from git repository it is enough to compile only jruby-core: then to find the compilation issue please remove the line: https://github.com/jruby/jruby/blob/master/core/pom.rb#L166 in case of missing SNAPSHOTs just remove the '-SNAPSHOT' in your core/pom.rb file but really surprised about compilation issues on ubuntu - let's see if you are able to get more insight |
Ok here is what I got so far:
Result: BUILD SUCCESSFUL
Result: BUILD FAILURE
After this there is a hs_err_pid16180.log and core file in the core folder. The log file shows the aforemented SIGSEGV. Then I removed the mentioned line in pom.rb and tried again with mvn clean; mvn -pl core. I'll try and bisect with this line removed from the pom.rb on every step. |
@obfuscoder yeah sorry I also missed you were having issues compiling. I think this is the first time I have ever seen anyone not compile with a crasher. If things are not too personal can you gist the hs_err file? My only random guess it fork for compile and is partially compiling with the wrong version of Java (and by partial I mean it is something like wrong java.home is getting called with a new java -- or somehting like that). I think we switched back to forked compiles because jruby + truffle was exhausting some resource all in the same process. |
There are not many cases where binding can be null. One of them is in the proc that results from I can reproduce a similar backtrace using a to_proc'ed Hash:
|
The other possible cause would be a "null block" somehow getting into instance_exec. However I am unable to cause that to happen from Ruby code. The I am not sure this is the cause, but in any case this proc needs to be fixed. The proper way to provide a custom block implementation is to implement BlockBody, not Block. Here's a possible fix. It makes my contrived example work: https://gist.github.com/headius/d220bcc94c92ffe800920a27a8841e68 |
The old impl was a custom Block implementation with a null block and binding, which caused many issues when methods like instance_exec attempted to break it into consitutent pieces and use them separately. This may help #4037.
I pushed a simpler fix to master: I moved This will have reduced perf compared to the native version, but perhaps not too much...and it's correct for all these cases. We need to add some specs for |
Additional tweak and specs pushed to master. @obfuscoder Can you verify that this fixes your issue? |
hmm ... but |
@kares we wondered the same thing but if they are updating to 9k perhaps they updated some gems as well? |
I did not update gems between changing the JRuby version. |
@obfuscoder interesting all of those are anyway if this is the case could you please try master (or a SNAPSHOT from http://ci.jruby.org/) as @headius already did changes (as seen above) where a to_proc's binding won't be |
Hmmm I do not quite have any realistic scenario here but perhaps something is checking to see if something can be a proc (via respond_to? :to_proc or other builtin explicit conversion) and doing something else if not....BUT.... in 2.3, hashes now respond to it so it invokes it on the hash. If that is the case, then likely some code may stop working as expected but with @headius fix it should then show a Ruby type error and not a crash. |
It looks like the to_proc fix is at least in the right neighborhood based on @obfuscoder's bisect, so we'll call this fixed on master. |
I plan do test this tomorrow |
After compiling master branch at 4cb79c1 I could successfully run the tests which used to fail with the NPE before. |
@obfuscoder thanks for the confirm. |
would have been another potential fix for #4037
Environment
I get an NPE on a lot of occasions: running specs, creating/persisting model instances
Here it is ( I'm afraid it is quite large):
The text was updated successfully, but these errors were encountered: