Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Possible incompatibility with Sorcerer in 188.8.131.52 + 184.108.40.206 #4629
Provide at least:
I’m having a problem with JRuby 220.127.116.11 and 18.104.22.168; when I run my test suite, I get a bunch of output like this before my tests run:
…I might get 8 or 9 of these print out if I run a small test file, and ~100 if I run my entire test suite.
Clearly the exception is happening in Sorcerer, and looking at my
The thing is, none of these gems have changed for a good while. The most recent change was to
I apologize I can’t supply any test code to reproduce; I’m hoping the stack trace above might be enough of a clue to at least start looking into this.
(Any chance this might be related to #4574?)
So these errors are not breaking your suite, is that correct?
Unfortunately the trace you provided is too general for us to really figure this out. It may be related to #4574 or it may not.
It's possible we "fixed" something that was swallowing error output and now it shows up. It's possible there's actually a bug we introduced. I'm not sure.
Correct. But they just make me worry about some possible regression somewhere that’s breaking something that I don’t have proper test coverage of.
I’ve tried to create a small isolated test file that would reproduce the problem but so far I’ve had no success.
But I have been able to produce a full stack trace:
Full stack trace
Does that help?
It helps, but you might be able to do more digging that would help more. It looks like at that point in the code, the
My guess is that there's something about the source processing this does that fails on JRuby, but instead of a hard error it's propagating a nil s-expression this far, and so we get the trace you provided. Unfortunately that doesn't show us how the nil sexp is getting created. Hopefully you can track that down with a little debugging.
I just noticed another difference in the outcomes when running my test suite.
With JRuby 22.214.171.124:
@aviflax yeah doubly interesting that I made 2 changes in line output for source between .10 and .11 but your coverage didn't change. They should not have been visible changes in this regard (one was an optimization and one was a correctness fix for uncommon syntax) but still happy to not see those cloud your problem more.
Let us know when you find out more and we will help as we can...
Hmm well I’m not sure I directly and specifically compared the coverage numbers between .10 and .11… I think I just assumed that .9, .10, and .11 were all the same — let me check… OK, I just ran the suite on .10 and got a different result: 96.09%.
So, to summarize:
And it looks like I made an error when above I reported coverage of 81.82% for .11 — that’s actually the coverage level for that specific file that Simplecov reported had dropped below the threshold. My minimum threshold is 90%, so this means that on .8 this file (which just defines a bunch of contracts using Contracts.ruby) has >= 90% coverage while on .11 it has 81.82%.
FWIW… I’m really not sure what this means. HTH!
@aviflax thanks for the data. The specific fix for .11 was that when we had an fcall ('foo' not 'b.foo') and its arguments spanned lines we would erroneously say the fcall happened on the line of its last argument and not the line where 'foo' is. I would have thought if anything this would have increased coverage since we are generating more line info than before not less?
I do wonder if my optimization maybe is the issue. If we had a case where we had n lines of consecutive line_num instrs we would only emit the last one since no exception could trigger until after that sequence. The problem with this logic is our line_num and trace instrs are tied to the same logic so perhaps I still need to emit n trace instrs so coverage reports empty lines are doing something? I guess I will need to look into that.
Glad to be of some help. This is all a bit over my head but I would love to help however I can to get to the bottom of this issue (the symptom being the
I’ve made a little progress on the “syntax error, unexpected end-of-file” etc errors.
When I run this in
require ‘ripper' Ripper::SexpBuilder.new('Then do').parse
with JRuby 126.96.36.199, the second expression returns
with JRuby 188.8.131.52–184.108.40.206, the second expression returns
So… I don’t want to jump to conclusions, but since Ripper is part of the Ruby stdlib rather than a third-party dependency, I would think that this difference in behavior would have to be caused by some change in JRuby — a change that was first released in 220.127.116.11.
Is that maybe enough to go on to investigate this further?