<jmalves_>
@headius I am able to reproduce https://github.com/jruby/jruby/issues/6282 only when using --dev flag. We use that flag when running our specs. I will update the issue soon.
<jmalves_>
Also found another error that appears around 50x more commonly than the NPE :/
<jmalves_>
(this one only appeared in this reproduction script not in our software code)
drbobbeaty has quit [Ping timeout: 256 seconds]
<subbu>
jmalves (a) is bug reproducible without an eval? (b) is the bug reproducible in a pure ruby run (vs. having to cross the ruby - java language boundaries)?
<subbu>
headius it might be worthwhile getting an IR dump of the ruby block ... I no longer remember the incantations necessary to get that dump.
<subbu>
I still have this alias lurking around alias debug_ir='jruby -d -J-Djruby.logger.class=org.jruby.util.log.StandardErrorLogger -J-Djruby.ir.debug=true -J-Djruby.backtrace.style=raw -X-C' but, that is probably going to be a ginormous dump with a 50K loop.
<subbu>
I still have this alias lurking around alias debug_ir='jruby -d -J-Djruby.logger.class=org.jruby.util.log.StandardErrorLogger -J-Djruby.ir.debug=true -J-Djruby.backtrace.style=raw -X-C' but, that is probably going to be a ginormous dump with a 50K loop.
<jmalves_>
@subbu I will try (a) and (b) tomorrow if I can get the time to it
jmalves_ has quit [Remote host closed the connection]
jmalves has joined #jruby
jmalves has quit [Ping timeout: 256 seconds]
multislacker[m]1 has left #jruby ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
smarks[m] has left #jruby ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
rabidmonk[m] has left #jruby ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
venkatkms[m] has quit [Quit: Idle for 30+ days]
aemadrid[m] has quit [Quit: Idle for 30+ days]
kasaltie has left #jruby ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
nirvdrum has quit [Ping timeout: 240 seconds]
nirvdrum has joined #jruby
<headius[m]>
Well sounds like we are narrowing in
Freaky has quit [Quit: reboot]
<headius[m]>
I will try --dev
Freaky has joined #jruby
<headius[m]>
That might explain why you only see it during aspect runs, since I assume you're using that flag to speed them up a bit
jmalves has joined #jruby
jmalves has quit [Ping timeout: 240 seconds]
<headius[m]>
jmalves_: GOT ONE
<headius[m]>
oh man I got both
<headius[m]>
yeah --dev is the ticket
<headius[m]>
happening almost every run, one or the other
<headius[m]>
now I will try this on master
<headius[m]>
FWIW your test case is fine... I was trying to develop mine in a vacuum and it clearly doesn't hit the same logic that fails
<headius[m]>
aha there's an AIOOB on master
<headius[m]>
come on NPE
<headius[m]>
I think I know what the AIOOB is
<headius[m]>
we're allocating a scope for one form of the code and then the optimize runs and we switch to the other form
<headius[m]>
just more lack of atomicity in the changeover from startup to full
<enebo[m]>
yeah that is almost always the problem with those backtraces
<headius[m]>
enebo: running his example with --dev in a loop makes it pretty easy to repro now
<headius[m]>
I'm getting the AIOOB 10x as much as NPE
<enebo[m]>
So we have a live scope which tries to call a new one
<enebo[m]>
headius: as a test for fixing you could disable removing scope as an optimization
<headius[m]>
can I do that alone without disabling ACP pass?
<enebo[m]>
NPE could be different but AIIOBE is always that
<headius[m]>
you're right that's most likely it
<enebo[m]>
well it would be disabling ACP I think
<headius[m]>
it's ending up with the previous scope which is empty and trying to use it
<enebo[m]>
Life cycle woes
<enebo[m]>
I believe there is another open issue with an AIIOBE as well
<headius[m]>
I am not getting NPE on master so far
<headius[m]>
that doesn't indicate it's fixed but all I'm seeing are OOB
<headius[m]>
OOB on about half the runs
<headius[m]>
ok that's like 20 minutes and I'm only getting the OOB
<headius[m]>
so master might have reduced the impact somewhat
jmalves has joined #jruby
jmalves has quit [Ping timeout: 260 seconds]
ur5us has joined #jruby
snickers has joined #jruby
<jeremyevans>
headius[m]: failure yesterday appears to be due to jdbc-sqlite3 behavior for fractional seconds with more than 999.5 milliseconds. jdbc-sqlite3 implicitly rounds up, whereas to_i rounds down. So it's a test bug that manifests on jdbc-sqlite3 roughly once every 2000 runs.
<jeremyevans>
headius[m]: I'll fix it :)
<headius[m]>
So this is a behavior of the JDBC driver then?
<headius[m]>
thank you for looking into it, I'm glad it was something simple!
<jeremyevans>
headius[m]: I believe so. Sequel sends: INSERT INTO `a` VALUES ('2020-06-10 11:12:21.999500'), then SELECT CAST(strftime('%f', `a`) AS NUMERIC) FROM `a` ORDER BY `a` LIMIT 1, which returns 22
<jeremyevans>
headius[m]: Actually, looks not to be JDBC issue, but SQLite in general. Also happens on CRuby using sqlite3 driver
<headius[m]>
that's an even better answer
victori_ has joined #jruby
<headius[m]>
enebo: before you check out for the day maybe we can chat quick about .12
<headius[m]>
I think this IR race should get in there once we fix it and we should audit other compact fixes on master
<enebo[m]>
yeah I think very much blocker only sorts of bugs where we can reason through it being solid
<enebo[m]>
regressions also are worthy
victori has quit [Ping timeout: 256 seconds]
<enebo[m]>
I think the only caveat to either is the perception of risk
<headius[m]>
this is the only one that comes to mind at the moment, since the serialization thing is already there
<jeremyevans>
Considering SQLite lacks date/time types, wonkiness in this area is unsuprising
<headius[m]>
yeah risk, keeping it localized to a few key fixes will help that
<enebo[m]>
I landed that ir persist thing yesterday
<enebo[m]>
I did think we had a few others from last month or so but I will need to look
<headius[m]>
jeremyevans: ah yeah that's a good point
<headius[m]>
Why doesn't it fail every time? Did this test just happen to be 9995 that once, or is it something else?
ludolf[m] has quit [*.net *.split]
robert[m] has quit [*.net *.split]
MattPattersonGit has quit [*.net *.split]
RomainManni-Buc4 has quit [*.net *.split]
fzakaria[m] has quit [*.net *.split]
UweKuboschGitter has quit [*.net *.split]
CharlesOliverNut has quit [*.net *.split]
headius[m] has quit [*.net *.split]
<jeremyevans>
headius[m]: I assume it only fails if microseconds are greater than 999500. It uses Time.now, so that should happen once per 2000 tries, on average
<enebo[m]>
yeah possibly so. I think it should not be a big problem since we will not be fixing too much
rebelwarrior[m]1 has joined #jruby
rebelwarrior[m] has quit [Ping timeout: 256 seconds]
snickers has quit [Read error: Connection reset by peer]
thomas[m] has quit [*.net *.split]
aoeuiiueoa[m] has quit [*.net *.split]
MarcinMielyskiG4 has quit [*.net *.split]
aoeuiiueoa[m] has joined #jruby
thomas[m] has joined #jruby
MarcinMielyskiG4 has joined #jruby
jmalves has joined #jruby
ludolf[m] has joined #jruby
robert[m] has joined #jruby
UweKuboschGitter has joined #jruby
fzakaria[m] has joined #jruby
CharlesOliverNut has joined #jruby
MattPattersonGit has joined #jruby
RomainManni-Buc4 has joined #jruby
headius[m] has joined #jruby
jmalves has quit [Ping timeout: 260 seconds]
<kalenp[m]>
cool, thanks for the interest! I'm with Looker, and the application is a fairly large web application which also does some heavy data processing on the side (we read and format result sets from the JDBC, so that's part of why we ended up on JRuby)
nirvdrum has quit [Ping timeout: 246 seconds]
ludolf[m] has quit [*.net *.split]
fzakaria[m] has quit [*.net *.split]
robert[m] has quit [*.net *.split]
RomainManni-Buc4 has quit [*.net *.split]
MattPattersonGit has quit [*.net *.split]
UweKuboschGitter has quit [*.net *.split]
headius[m] has quit [*.net *.split]
CharlesOliverNut has quit [*.net *.split]
<kalenp[m]>
we're in the process of trying to upgrade our runtimes to get some more performance. our goal is the latest jruby + java11. we just upgraded from 9.1.17 and found that 9.2.9 was the latest version which worked with us. 9.2.8 and 9.2.10+ both had threading issues that we hit
<kalenp[m]>
yup, and some already fixed (thanks!). I can find the particular issues on github
<kalenp[m]>
would definitely appreciate that
<kalenp[m]>
it looks like 9.2.9 has java11 compatibility issues, so that put a bit of a blocker on our ability to get up there.
<kalenp[m]>
one moment while I root around in github
<kalenp[m]>
That would be great. One fewer variable in the testing/environment matrix.
simi[m] has joined #jruby
elisabeth[m] has joined #jruby
elisabeth[m] has joined #jruby
elisabeth[m] has quit [Changing host]
thomas[m] has joined #jruby
<kalenp[m]>
As far as we know, our java11 compatibility issues were resolved in 9.2.10. It's just that the threading issues prevent us from getting there https://github.com/jruby/jruby/issues/5969
aoeuiiueoa[m] has joined #jruby
MarcinMielyskiG4 has joined #jruby
ludolf[m] has joined #jruby
<kalenp[m]>
Yup, we're using kotlin. Writing some internal libraries in it and rewriting some performance critical code in kotlin as well. Definitely appreciating the ability to transition from dynamic to static languages within the project.
robert[m] has joined #jruby
MattPattersonGit has joined #jruby
fzakaria[m] has joined #jruby
RomainManni-Buc4 has joined #jruby
UweKuboschGitter has joined #jruby
CharlesOliverNut has joined #jruby
headius[m] has joined #jruby
KarolBucekGitter has joined #jruby
ilikeorangutans[ has joined #jruby
OlleJonssonGitte has joined #jruby
byteit101[m] has joined #jruby
olleolleolle[m] has joined #jruby
BlaneDabneyGitte has joined #jruby
ahorek[m]1 has joined #jruby
liamwhiteGitter[ has joined #jruby
daveg[m] has joined #jruby
TimGitter[m]2 has joined #jruby
JulesIvanicGitte has joined #jruby
TimGitter[m]1 has joined #jruby
<headius[m]>
cool no argument there
<headius[m]>
this makes that kotlin issue a higher priority then
<headius[m]>
if you get a chance you could try the workaround mentioned there, I think it's @JvmStatic for companion objects
<headius[m]>
I have not figured out a good way for us to detect companion object/class apart from any other inner class or static field
<kalenp[m]>
Oh, I've tried all the workarounds. That's my bug :D
<kalenp[m]>
* Oh, I've tried all the workarounds. That's my bug
<kalenp[m]>
* Oh, I've tried all the workarounds. That's my bug 😛
<kalenp[m]>
Based on the discussion and our testing, it's functioning properly, so it's not a blocker. We let customers self host and it's the sort of warning that might raise eyebrows if somebody's looking at the logs, so we're capturing and suppressing it for now.
<kalenp[m]>
Of course, a real fix would be ideal, but from the discussions on the ticket, it seems like there's going to be a bit of guesswork involved.
<headius[m]>
oh hahah I didn't even notice
<headius[m]>
yeah I'd like to have a better indicator that some inner class is a companion class but it needs more research
<headius[m]>
ok that's enough mucking around on facebook for one day
<headius[m]>
why doesn't github let me clone issues