sagax has quit [Read error: Connection reset by peer]
sagax has joined #jruby
<mattpatt[m]>
Okay, that's weird - something's popped /usr/bin off the end of $PATH when it gets to the failing spec, which is why the shell can't find `zip` (or `which`)
<MateuszFryc[m]>
Hmm, I am not sure if my mail reached proper people, I din't get any reply about a failure from smtp server, but didn't get any confirmation that email reached proper people. Is this normal? In archived list of issues https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/ there is no my issue listed. Additionally I tried to subscribe to the list, but no reply message showed up in my mailbox so far. Issue occurred already 4 times
<MateuszFryc[m]>
in my production environment on 3 out of 4 servers which crashing software is installed. Only on the weakest machine it hasnt happened yet. I hope my mail reached the group.
<MateuszFryc[m]>
* headius: Hmm, I
<mattpatt[m]>
@enebo I have an idea...
siasmj has quit [Ping timeout: 256 seconds]
siasmj has joined #jruby
<MateuszFryc[m]>
headius: just for your information, I also submitted an issue on oracle bug submission sites, following some information about how to proceed in such a cases if one have no access to JBS. And received following feedback: "We will review your report and have assigned it an internal review ID : 9071983. Depending upon the completeness of the report and our ability to reproduce the problem, either a new bug will be posted, or we will
<MateuszFryc[m]>
contact you for further information." So when someone assesses it is a bug, it should show up in some publicly accessible database I guess, then one will be able to link it to jruby bug issues tracker if needed.
<headius>
Yo
<headius>
Mateusz Fryc: I do not see your email either. May be moderated
<headius>
Oracle bug submission is good. I will try to post to the compiler list if your email does not show up today
<headius>
Maybe I should just have filed a JBS bug but I'm skittish
<headius>
I suppose I could also raise it directly with the red hat JDK folks since I'm technically on that team
<mattpatt[m]>
seems like there's a helper method that resets `ENV['PATH']` and never sets it back
<mattpatt[m]>
the spec that calls it is guarded in a way that makes me think that maybe it just never ran on Travis
<mattpatt[m]>
What's really weird is that I tried altering it so that `ENV['PATH']` gets reset at the end of that spec with an ensure block on the method, but it doesn't seem to get called.
<mattpatt[m]>
headius: yeah, managed to get it passing, but in a horrendously brittle way
<mattpatt[m]>
no idea why the ensure didn't work
<mattpatt[m]>
Okay, got a version that works. Think the previous non-execution of the `ensure` was down to execution context/thread stuff
<mattpatt[m]>
caused by me being daft
<enebo[m]>
mattpatt: Perhaps we are throwing an internal error
<enebo[m]>
We run so many tests too that it becomes easy to miss partial execution of stuff because there are a lot of logs
subbu has joined #jruby
<mattpatt[m]>
not here - I have been running just spec:ji on a just JDK 8 in a branch
<mattpatt[m]>
and grepping the logs for debug `puts`s
<enebo[m]>
so can you repro that ensure is not running?
<mattpatt[m]>
I think so - tweaked it several times adding more debug output
<enebo[m]>
ah ok I did not think there were that many but it makes sense
<mattpatt[m]>
to run with -d I can do `jruby -d -S rake ...`
<mattpatt[m]>
not an arg passed to rake
<enebo[m]>
yeah
<enebo[m]>
undefined local variable or method `original_env_path' for #<RSpec::ExampleGroups::RakeAntAnt:0x752e4223>
<mattpatt[m]>
great, it's much simpler if i was being an idiot
<enebo[m]>
Unless you changed from the ensure I find that really weird
<mattpatt[m]>
`orginal_env_path` and `original_env_path`. 👍️
<enebo[m]>
mattpatt: can you change that method from doing def; ensure;end to def; end with a begin;ensure;end within it?
<mattpatt[m]>
sure
<enebo[m]>
This error if it is from the code linked above implies tyhat original_env_path is not seeing a local variable scope and thinks it is a vcall (e.g. method with no parens or params)
<mattpatt[m]>
I think the ensure was always running, i just couldn't type
<enebo[m]>
ok but that specific error in the run shows that it is aborting on original_env_path not being found
<enebo[m]>
which would be above your puts in that last commit
<enebo[m]>
I do doubt we broke def a; ensure;end since although uncommon it is not that rare but it looks like it thinks it is a vcall
<mattpatt[m]>
yeah - it was aborting before it to my debug `puts`, and it couldn't reset `ENV['PATH']`, so I was seeing the spec with `zip` still failing
<mattpatt[m]>
so I think the problem was squarely between brain and keyboard, and not with `ensure`
<mattpatt[m]>
it's working fine in my latest version of the solution
<enebo[m]>
yeah and I can confirm ensure is firing too
<mattpatt[m]>
will tidy up a bit then submit a PR
<enebo[m]>
mattpatt: great
<mattpatt[m]>
enebo: is there a rule around trailing whitespace in files? my editor is set to remove it, and it hasn't been a problem with other JRuby source files I've worked with, but `spec/java_integration/utilities/jar_glob_spec.rb` has a load of empty lines with trailing whitespace...
<enebo[m]>
I never remember &w=1 and they keep changing their UI
<mattpatt[m]>
looking good here
subbu has quit [Quit: Leaving]
subbu has joined #jruby
<headius>
Oh looks good so I merged!
<headius>
What a weird piece of code
<headius>
mattpatt: nice find!
<mattpatt[m]>
when I saw that `$PATH` was only missing `/usr/bin` I figured it had to be something else in the test run mutating it
<headius>
Yeah makes sense
drbobbeaty has joined #jruby
subbu has quit [Ping timeout: 265 seconds]
<headius>
odd, my addrinfo fix did not seem to work on GHA
<headius>
oh boo I targeted master
<headius>
ok so test:mri:stdlib should be green then
<headius>
enebo: I should have checked this before... some of the spec failures have "travis" tags
<headius>
so they were failing on travis too but are not being masked on GHA
<headius>
do any specs fail for you locally on fedora?
<headius>
I'm doing a run locally under docker ubuntu 20.04 and will also inspect these other failures
subbu has joined #jruby
<headius>
some of these look like it's running ipv6 specs when ipv6 is not present... I see checks for this in the specs but we are probably defining all the constants all the time so it thinks they should work