<headius>
kares: btw, I think enebo wants to put out 9.0.5 this week, and then we're just going to merge ruby-2.3 in
<kares>
headius: should the AssertionError re-throw in LoadService be kept or should I skip that commit while pushing upstream?
<kares>
headius: najs!
<headius>
kares: probably should not stay but I'd like to know why it was masking failures
<kares>
headius: ok - going to push to master without it than
<kares>
on first look catch(Throwable) feels wrong - e.g. OutOfMemoryError re-packed into Ruby LoadError but I have not tested MRI and there are no reported issues so guess its good :)
<GitHub158>
jruby/master 9fc39a4 kares: adjust LoadService exporting a private class for sub-classes + list of <String> please
<GitHub158>
jruby/master 5f7551d kares: this seems obviously as a missing throw statement
<GitHub158>
jruby/master fcc07a4 kares: align where catch(Throwable) stack traces are printed + find-bugs-style cleanup
<kares>
new failures where false alarm on my end ... thus the next travis-ci is expected green!
<eregon>
headius: Hi!
<headius>
eregon: hello
<headius>
kares: ok excellent!
<headius>
kares: it probably should be catch (everything that's not Error) and propagate Error
<eregon>
headius: The question of making JRuby+Truffle Java 8 came up again, what do you think if the jruby-truffle.jar was Java 8 and core JRuby Java 7 bytecode?
<headius>
I'm wary to change it, though, since there are libraries that want to be able to rescue LoadError to swallow all potential reasons a library might fai l to load
<headius>
eregon: since they're shipped as separate jars I don't see a problem with it
<headius>
we can chat with enebo about it today
<eregon>
that would be great
<kares>
headius: agreed some Error types make sense e.g. ExceptionInInitializerError for java exts
Puffball_ has quit [Read error: Connection reset by peer]
<eregon>
ping me when he's around then :)
Puffball has joined #jruby
csfranci1 is now known as csfrancis
e_dub has quit [Quit: ZZZzzz…]
tomjoro has quit [Remote host closed the connection]
tomjoro has joined #jruby
tomjoro has quit [Ping timeout: 264 seconds]
<headius>
kares: we could also have a subclass of LoadError that propagates more info when it's a Java error
<headius>
FYI all, I'll be working on slides for FOSDEM this week so not hacking much, but I'll be around
<bga57>
If it's there, it's at the Day Block Brewery, 1103 Washington, upstairs
<enebo>
headius: so in your idea it would not be to deopt but to retry?
<headius>
yeah, branch over to the object-based logic from then on
<headius>
or that could be used as a sign to do a heavy deopt without adding a lot of exception-handling around unboxed operations
<headius>
if we value-doubled we wouldn't have to fully deopt though
<enebo>
headius: I think right now a deopt strategy proposed would be to raise a saved instance of an exception saying, “deopt” which would be likely a full deopt
subbu is now known as subbu|meeting
<enebo>
headius: I guess the need to keep return primitive is the motivation right?
<headius>
yes
skade has quit [Ping timeout: 264 seconds]
<enebo>
headius: seems reasonable to me but as an if in IR means it will end up being 2 BBs and I wonder about analysis since one path will be primitive and one will be object (although it seems better than one path which is always Object)
<enebo>
headius: this split-if is why our current inliner is not the greatest
<enebo>
headius: but with that said it still improves things
bb010g has quit [Quit: Connection closed for inactivity]
<enebo>
ah anyways this is why we need a generic deopt since unboxed math at least for things like arith. we can assume primitive return and force deopt. Then though our IR will be all primitive and it potentially can lead to more discovery
<enebo>
but it might still be a good short run opt if we can unbox with fail path for now?
<bga57>
BTW, tonight's ruby,mn meeting is a meetup with Sandi Metz.
<enebo>
headius: yeah I think it only succeeds after first run because problem gem is thought to be installed after previous failure
<headius>
I got a bunch of these so I think my gems got corrupted:
<headius>
Invalid gemspec in [/Users/headius/projects/jruby/lib/ruby/gems/shared/specifications/rspec-support-3.4.1.gemspec]: undefined method `prerelease?' for nil:NilClass
<enebo>
wow
<enebo>
I am only seeing: ERROR: While executing gem ... (TypeError)
<enebo>
nil can't be coerced into Float
<headius>
my issues was a local problem from unboxing work
<headius>
enebo: still rebuilding after patching that
<enebo>
headius: yeah I think either my assumption on block var CP was wrong (parser-only) which I think it will be ok as-is or kares making a seemingly obvious change to raise is a mistake
<enebo>
unless ASM is broken
<enebo>
but I can test that one quickly by running interp only
<headius>
I just passed --verbose and --debug to install
<enebo>
yeah ok I have it also now
<enebo>
same line
<headius>
timeout does return nil for us if not set
<headius>
MRI appears to always return a numeric result from SSL_SESSION_get_timeout
<enebo>
@ssl_session.timeout
<enebo>
hmmm
<enebo>
so this must be newish no?
<enebo>
I mean we just released 1.7.24
<enebo>
perhaps we are using a newer jossl on 9k
<enebo>
I don’t really follow this gem as much
<headius>
somewhat new
<headius>
timeout is 300 at that line in MRI
<headius>
5 min
<headius>
not sure if that's an openssl default or an MRI default though
<enebo>
hmm
<enebo>
could it be retrieved?
<enebo>
like a ttl from the server thing?
camlow325 has quit [Remote host closed the connection]
<headius>
no reference to 300 in all of ossl
<headius>
certainly could be, I don't know
camlow325 has joined #jruby
<headius>
"Whenever a new session is created, it is assigned a maximum lifetime. This lifetime is specified by storing the creation time of the session and the timeout value valid at this time."
<headius>
"The default value for session timeout is decided on a per protocol basis, see SSL_get_default_timeout. All currently supported protocols have the same default timeout value of 300 seconds."
<headius>
openssl docs
<enebo>
hmm
<enebo>
ok well that sounds like it is coded into the lib
blaxter has quit [Ping timeout: 245 seconds]
<enebo>
so we would have that value but MRI would not
<headius>
right
<headius>
I'm looking at javax ssl stuff
<enebo>
headius: I am wondering if this is the only problem if we just hack http to check 300 here with an issue or we fix jossl on the spot
<headius>
hmmm yeah, I dunno
skade has joined #jruby
<headius>
it would be a small fix if this is the only place
skade has quit [Read error: Connection reset by peer]
<headius>
it doesn't work in current jruby-openssl because it needs an "ssl context" to have been established to report the timeout
<headius>
for this case I assume it's not there because otherwise it would provide a fixnum result
<enebo>
webrick/ssl.rb has a config for setting timeout but I do not see a default
<enebo>
so I wonder if it is an issue or not there too
<enebo>
since I do not see anything consuming the timeout I am not sure I can know or not
<headius>
well the patch for ossl is simple enough for now...I'll just have it return 300
<headius>
trying to figure out of there's a default for java ssl or not
<donValentin>
Hi all!
<enebo>
headius: ok
<enebo>
donValentin: did you nick just get longer or are you someone else?
<donValentin>
It is my alternate nick for when IRC gets confused :)
<enebo>
headius: seems we should revv jossl to be safe…my grepping did not look horrible but it feels like I would hit myself if I did a hack like that and it failed
<donValentin>
I am donV :)
<headius>
enebo: ok
<enebo>
donValentin: ok…I keep forgetting what V stands for
<donValentin>
That’s why I use this nick once in a while, just to remind you :)
<enebo>
donValentin: thank you :)
<donValentin>
Gratz on the 1.7.24 release. It seems to work well on Ruboto.
<headius>
enebo: trying with 0.9.15-SNAPSHOT of jossl
<headius>
seems to have worked
<enebo>
headius: yeah makes sense it would unless we had other code depending on it being nil
<enebo>
headius: but this bugs me a little bit…how did this start triggering?
<enebo>
headius: like some server-side change from rubygems.org perhaps?
<GitHub115>
[jruby-openssl] headius pushed 2 new commits to master: https://git.io/vzPZC
<GitHub115>
jruby-openssl/master aefb6c3 Charles Oliver Nutter: Always return a Fixnum here. openssl defaults to 300.
<GitHub115>
jruby-openssl/master 79af044 Charles Oliver Nutter: Rev pom version.
<enebo>
Seems very possible to me but I wonder if now whether jruby-1_7 is broken
<headius>
it's possible...I only got a couple 300 prints for dozens of gems in rails so it may be doing keepalive now or something?
<headius>
we were defaulting to 0.9.13 on master up to now btw
<enebo>
I guess I will clone 1.7 and try it
vmarcetic has joined #jruby
<enebo>
hmmm I wonder what was 1.7
<headius>
1.7 appears to use 0.9.13 too
skade has joined #jruby
<enebo>
yay
<headius>
but this may not exist in 1.7 stdlib
<enebo>
yeah maybe not
<headius>
do not know why it would have started breaking recently though
<enebo>
building 1.7 in a fresh clone (seems easier than dealing with gemhome)
<headius>
my changes are pushed to jruby-openssl...you can mvn install and then update jruby lib/pom.rb to point at 0.9.15-SNAPSHOT to test
<enebo>
headius: since you are testing perhaps you can see what we have commented out in MRI openssl tests
<enebo>
we must have had this one not running
<enebo>
or perhaps we don’t run all ext tests
<headius>
those lines in http.rb haven't been updated since we pulled in 2.2 stdlib
<headius>
fyi
<enebo>
yeah so seems like it is likely a server change having us hit that logic
<headius>
I'm not sure we run the session tests at all
<headius>
it was only partially implemented recently
<enebo>
ah
<enebo>
well I sure hope this passes :)
<enebo>
yay…I still have debug flags in here
<enebo>
well seems like it did not error on 1.7
<enebo>
so that begs a different question about how safe 1.7.x is over time since no one is updating some of these stdlibs any more
<enebo>
heh…so something it decided to set the value we are returning as 300 unconditionally now
<headius>
not unconditionally
<enebo>
oh only if not set
<enebo>
ok
<headius>
yeah
<enebo>
so what is this warning saying…we can read and set the value but nothing uses it?
<headius>
that warning comes up with there's no context established
<headius>
so same reason the other method returned nil
<headius>
we can read it and set it but if context is not established we have nowhere to put it in java APIs
<headius>
I have not been able to learn what the lifecycle is for ssl session context
<enebo>
ok so I can run my runner to install rails and make a sample rails app with this change
skade has quit [Ping timeout: 240 seconds]
<enebo>
yeah so there could be lots of breaking behavior here in the case the session timeout is important
<enebo>
but probably not a big deal in normal case
<enebo>
I mean if the lifecycle is potentially wrong then perhaps we have other landmines here too
<headius>
well it doesn't seem like the context is associated with a live connection or anything, so I'm trying to see if we should be more eagerly triggering it
<headius>
but yeah without lifecycle knowledge I'd be really worried about a larger change
<headius>
docs on these classes are so poor
<headius>
A SSLSessionContext represents a set of SSLSessions associated with a single entity. For example, it could be associated with a server or client who participates in many sessions concurrently.
<headius>
no way to construct it, no indication of what creates it
<headius>
"This context may be unavailable in some environments, in which case this method returns null."
<enebo>
another option to consider is whether we fall back to 9.11 for 9.0.5.0 or if there is a critical change we need
<headius>
there's a lot of code examples that assume it's never null
<headius>
hmmm
<enebo>
hmmm I wonder if MRI just has a stack struct of it
<enebo>
I would think even MRI would need these to be thread local
<enebo>
or hell sorry per connection
<headius>
yeah
<enebo>
GetSSLCTX(self, ctx);
<enebo>
SafeGetSSLSession(arg, sess);
<enebo>
I see these two lines all over the place
<headius>
in our source?
<enebo>
not always right next to each other though
<enebo>
in MRI’s
<enebo>
Just thinking it might inform on lifecycle at least as much as MRI is correct about lifecycle
<enebo>
which I hope is totally correct
<headius>
hmmm yeah
<enebo>
an ex-coworker had to do a bunch of crap for us with openssl many years ago and it was super difficult to know for sure :)
<enebo>
ossl_sslctx_s_alloc(VALUE klass) and a free method I can see
<enebo>
ok so SSLContext has an alloc function which allocates this struct
<enebo>
So any SSLContext.new will make one
<enebo>
I guess that might mean all ext methods define assume an instance of this has been made in Ruby already to work
<enebo>
or they call alloc/new internally in C somewhere
<enebo>
I know nothing about this library so I am just spelunking
<enebo>
BUT … If we are missing something critical with lifecycle of openssl I really don’t feel comfortable rolling with it a day later
<headius>
hmm
<headius>
yeah
subbu is now known as subbu|lunch
<enebo>
so we have three options
<enebo>
1) we fall back to 0.9.11 which 1.7.x uses. Will this cause problems with stdlib 2.2?
<enebo>
2) we just make the single timeout change.
<enebo>
3) We spend some more time to figure out why context is null and fix it
<enebo>
3 feels the most risky so I think we should do that soon but not use it in this release
<enebo>
1 I have no feeling for so I don’t think I should argue for or against it
<enebo>
2 obviously works enough to pass our acceptance testing but it mildly gives me feelings of fear :)
<headius>
the single timeout change = in jruby-openssl right?
<enebo>
I guess maybe another thing going for 1) is that it was what we released for 9.0.4.0 and we have not had issues reported
<enebo>
headius: correct
<headius>
there's a lot of changes since 0.9.11
<headius>
I don't think we can go back older than 9.0.4 though
<enebo>
headius: you mean ones in JRuby which depend on them
<enebo>
headius: if so then yeah I agree
<headius>
ok yeah, reconfirmed 9.0.4 used 0.9.11
<headius>
I mean changes in jruby-openssl since 0.9.11
<headius>
there's lots of commits
<enebo>
oh yeah
<enebo>
ok so #1 is still a candidate
<headius>
it was released in august
<enebo>
in my mind fixing openssl bugs may or may not be a big deal for 9.0.5.0 unless people are dead in the water with 9.0.4.0
<enebo>
if they are then we obviously have a harder decision to make
<headius>
given that this small item is broken I'd vote for keeping jossl the same
<headius>
kares just updated it on master on dec 21: 1df6315e
<enebo>
headius: the same meaning 0.9.11
<headius>
yes
<headius>
seems like he only updated it because it pulls in some features missing from 2.2 and 2.3
<enebo>
headius: ok that is my default instinct :)
<enebo>
kares: are you around?
<headius>
so I'd say we hold back on that, spin 9.0.5 with jossl 0.9.11, and look at getting jossl updated and verified for 9.1
<enebo>
headius: is kares is not online I think we should send an email and ask him how important the changes are since I know he also recently updated jruby-rack
<headius>
there might be other things that break from having a half-implemented SSLSession
<enebo>
headius: yeah seems like best plan barring any new info
<enebo>
I will set back to 0.9.11 and make some new bits
<enebo>
maybe we can feel good enough in the morning to push it out