NullPointerException in FrameUtil.getObjectSafe escaping from Interpreter #2156
Comments
|
@aardvark179 Could you take a look at this one? |
|
Hopefully the following is a simpler project with a GitHub workflow which shows the difference in behaviour between HEAD, 20.2 and MRI (the latter two behave in the same way). https://github.com/petenorth/gsub-tests/runs/1409321836?check_suite_focus=true The matrix provided to the workflow is made up of [2.6, truffleruby, truffleruby-head] these correspond to MRI, 20.2 and HEAD respectively. MRI and 20.2 fail but in an expected way, HEAD fails but due to a null pointer escaping from the interpreter. I'd like to create a simpler reproducer but this is the best i can do at the moment. It seems to be due to the passing of some ruby symbol to camel case in Whose method body is |
|
I've seen these as well. Can't give you a reproducer right now I'm afraid. |
|
@petenorth @chrisseaton Do you see this NullPointerException consistently or is it transient? |
|
I've not been able to reproduce this locally, so I'm not sure if it's a race or compilation bug. What I can do for now is improve the error reporting when this problem occurs which should help use narrow down where the problem is occurring in Ruby code, and whether we've made some assumption that is not actually valid. |
|
I experience it consistently on every run. |
|
Sorry I can't remember where I've seen it, but I definitely recognise seeing it. Sorry that's not very helpful. |
|
The |
|
|
@petenorth There are new |
|
Here are the results of the latest run https://github.com/petenorth/gsub-tests/runs/1418047935 |
|
I can reproduce it locally, thanks for the commands above, that was convenient. |
|
I see the similar issue on every run: An exception: |
|
Thanks, I could figure out what was going on with the mutant reproduction. def bar
yield
end
def foo
bar { } # The block captures svars
end
method(:foo).to_proc.call
fooFor Method#to_proc we create a dummy declaration frame, and so we end up storing special variables there. But then on the normal call there is no declaration frame, and the node gets confused. |
|
I've talked this over with @eregon and we have a couple of potential ways to fix this. It looks like it has been a potentially long standing bug, but has been thrown into sharp relief by the changes to how we create and access storage for special variables. I'll prototype our potential fixes and add some specs so we can work out which pattern will work best and introduce the fewest additional complications. |
|
A fix for this has been merged in 1861a67. I'll leave this issue open for a little while to give you all time to check this is resolved once there is a new build of truffleruby-head. |
|
For mutant gem I still see some issues, but not |
|
The cucumber tests are now running (i.e. the fix is working)! Thanks for the fixing this. Will the fix be included in a 20.3 patch release? |
|
We'll backport the fix to the 20.3 release branch, but it's not clear yet if there will be a release based on 20.3 before 21.0.0 comes out (est. 19 Jan 2021). |
|
@aardvark179 I think this can be closed now. |
I've started seeing the following exceptions when running Cucumber tests
https://github.com/petenorth/schools-experience/runs/1399517944?check_suite_focus=true#step:8:90
The text was updated successfully, but these errors were encountered: