-
-
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
Possible incompatibility with Sorcerer in 9.1.9.0 + 9.1.10.0 #4629
Comments
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. |
The issue is still present in 9.1.11.0. I hope to do some deeper debugging soon. |
I just noticed another difference in the outcomes when running my test suite. With JRuby 9.1.8.0:
With 9.1.9.0–9.1.11.0:
|
@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 |
@aviflax yeah the coverage numbers and the nil are likely to be unrelated but since you mentioned the numbers it will make me look at that part a bit closer since it is something I can examine. If you can isolate the nil issue a bit more we can tackle that. |
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 9.1.8.0, the second expression returns with JRuby 9.1.9.0–9.1.11.0, 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 9.1.9.0. Is that maybe enough to go on to investigate this further? Thanks! |
@aviflax cool! Yeah this should help |
Sorry to be a bother, but I’m just wondering if there’s any chance this Ripper behavior might be investigated any time soon? I’m eager to get my app back on the latest JRuby… thanks! |
…10.0. I am a big dope. Errant println removed!
@aviflax Can you verify you see no more poor output? I feel fairly embarrassed that I had an errant println I was using for debugging in there. So that explains the mysterious output (which only occurred in some syntax error scenarios). |
@enebo no worries — happens to the best of us! Thanks so much for following up! I’ll try to test today once I look into building JRuby from source. |
@aviflax great. Just reopen with details if you find anything. |
Looking good! Thanks @enebo! |
Environment
Provide at least:
jruby 9.1.10.0 (2.3.3) 2017-05-25 b09c48a Java HotSpot(TM) 64-Bit Server VM 25.131-b11 on 1.8.0_131-b11 +jit [darwin-x86_64]
Darwin Avis-Imprudence.local 16.6.0 Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 x86_64
Description
I’m having a problem with JRuby 9.1.9.0 and 9.1.10.0; 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
Gemfile.lock
it’s clear that Sorcerer is being used bygiven_core
which is used byminitest-given
— together those two gems provide the testing DSL I’m using and adapt the DSL to minitest, which I’m using to run the tests.The thing is, none of these gems have changed for a good while. The most recent change was to
given_core
which I upgraded in my project back in early March. So it seems that the cause of the problem is some change in JRuby, in either 9.1.9.0 or 9.1.10.0, as when I run my test suite with the same exact code and the same exactGemfile.lock
and everything, but on JRuby 9.1.8.0 or 9.1.7.0, I don’t see this output. (In fact my project has used every version of JRuby since 9.0.5.0 — I try to keep up with releases — and this is the first time I’ve seen this problem.)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?)
Thank you!
The text was updated successfully, but these errors were encountered: