-
-
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
Somehow super stopped working in jruby 9.0.5.0 #3643
Comments
Still failing on master today. Investigating. |
This appears to be a bug in the JIT. If I run your suite with only the interpreter, it passes. |
Wow, this is really hard to narrow down. It seems to only fail when the JIT is enabled, but the code that fails does not appear to be jitting. I'm wondering if we're getting a bad stack trace here... |
Ok...tiptoeing forward. The def execute
super
super
end |
Thank you for looking into this! This also happens on master of pork. In additionally, I tried to remove test files to reduce the scope. I found that just leave Wait a minute... I just tried to run Not sure why it's not always failing now. Randomness? Now this always works: both |
Since you mentioned that def execute
super
begin
super
rescue NoMethodError
require 'rib/config'
Rib.anchor binding
end
end I tried Could it be call site cache broke or something? |
I narrowed this failure down to test_stat and noticed the randomness also. I'm not sure where it comes from. |
I still have no new information except to say that it definitely does seem timing-sensitive. I added some logging to test.rb and the problem went away :-\ |
I bisected this to 27e6a64. I find it pretty weird this particular change caused an issue. One other thing I did notice is even with this reverted every so often (like 1 in 10 times) I see this CLI fail:
This will also fail even if in -X-C with a threshold of -1. Seems like a race. Whether it is related to the above problem or not I don't know. Anyways, reverting this definitely makes a big positive difference but it seems pretty critical for us to understand why. I also tried disabling BlotJITTask and that had no effect. Weird... |
@enebo Yeah that commit seems really unlikely to cause this problem...I'm surprised. Looking at this again today. |
Ok, after much fussing about, we've determined that the following method in pork is getting compiled incorrectly: def would desc=:default, opts={}, &test
@tests << [:would , desc , test || lambda{}, opts]
end Specifically, the
Note that Seems to a problem constructing and wiring up the global ensure block properly; it's disappearing. |
Please let me know if there's anything I could do, or I've written some bad Ruby code that should be avoided. I tried to change |
@godfat You did nothing wrong, this was just buggy. The trigger in your code was that the Two workarounds for you are to use Fixes plus test coming shortly. Here's the smallest repro I have right now: class A
def x(proc)
instance_eval(&proc) rescue nil
end
end
A.prepend(Module.new { def x(proc); super; super; end })
def foo
A.new.x(lambda{})
end
foo edit: fixed code to rescue nil for the ArgumentError |
Solution is found and fix is on the way. The bug caused bare lambda to not properly clean up frame stack when an exception was raised in argument processing. Argument processing was added to the entryBB, which never gets GEB (global ensure block) treatment. In addition, a culled GEB from earlier in processing was not properly cleared, so a new one was never created. |
Oh wow, impressive. Debugging is really hard! And actually that's also a bug on my side. I didn't know The only reason the test would still pass on other rubies is that I didn't check which exception was raised exactly from the test case, namely here: https://github.com/godfat/pork/blob/pork-1.4.4/test/test_stat.rb#L53-L56 It's only checking if there's a backtrace. I tried to add this line: expect(err).kind_of?(Pork::Error) Now it's failing. I'll commit the fix along with test tomorrow. The exception should be swallowed for reporting, but it should really be Interestingly, if I did right in the first place, then it would not trigger this JRuby bug. Once again I think buggy/sloppy codes are really capable to trigger a VM/server/platform bug. Thank you so much for the time! |
@godfat I'm very glad we were able to find this! We had received other reports of sporadic |
Awesome! :D |
discovered by: jruby/jruby#3643
Sorry I don't have simple reproducible code for this either.
Here's the trace:
https://travis-ci.org/godfat/pork/jobs/107027673
The line was:
https://github.com/godfat/pork/blob/pork-1.4.4/lib/pork/test.rb#L16
You can see that in line 13 that
super
works, but not the one in line 16.It used to work on jruby 9.0.4.0.
You could reproduce this by cloning the repo and run
jruby -S rake test
whenever dependencies were all installed.The text was updated successfully, but these errors were encountered: