00:09 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Fix issues with previous commit overzealously removing brackets 00:09
travis-ci.org/MoarVM/MoarVM/builds/371325397 github.com/MoarVM/MoarVM/compare/5...d79d869199
00:09 travis-ci left 01:12 MasterDuke joined 01:57 ilbot3 joined 02:11 [Coke]_ joined 02:16 Voldenet joined 02:19 benchable6 joined 03:17 coverable6 joined, evalable6 joined, releasable6 joined, statisfiable6 joined 04:14 yoleaux joined 05:53 domidumont joined 06:00 domidumont joined 06:38 robertle joined 07:47 zakharyas joined
lizmat good *, #moarvm 08:15
08:15 zakharyas joined
lizmat I have sad news: looks like the latest changes in Moar created a bunch of issues 08:17
mi6 stopped working: gist.github.com/lizmat/f7ce01f608c...ce2b4286ae
and after the most recent pull, "make install:
" doesn't work for me either anymore: gist.github.com/lizmat/b40058cee47...e3a0c888a3 08:18
it may be that I'm not quite awake yet, but both of these are pretty weird / mysterious to me at this point
lizmat tries a complete install from scratch 08:22
hmmm... a complete install from scratch is ok 08:27
lizmat nukes the install dir and tries again 08:28
new interesting failure mode on "make install": 08:33
No such method 'install' for invocant of type 'Str'
the string being "CompUnit::Repository::Staging" rather than a type object :-(
and now I'm back to the original error :-( 08:40
afk for a few hours& 08:41
08:50 ilmari[m] joined 08:53 brrt joined
brrt \o 08:53
nwc10 o/
brrt lizmat: that is bad news indeed 08:54
jnthn o/ 09:23
It'd be worse news if those things had landed before the release :-)
Currently testing a fix for github.com/MoarVM/MoarVM/issues/846 09:24
brrt true
Geth MoarVM: 1b78b04c02 | (Jonathan Worthington)++ | src/6model/reprs/NFA.c
Fix missing bounds check in NFA results push

After the binary search identifies that there is at last one edge matching and starts pushing the target states, we need a stronger condition to make sure we don't read past the end of the codepoint edges list, or get a false positive on a non-codepoint edge.
Fixes #846.		 09:28
09:29 AlexDaniel` joined, wictory[m] joined
nwc10 jnthn: I'd not yet built anything recent (past 2 days) with ASAN because t/spec/S17-supply/syntax.t is hanging (again) (no CPU burned) and I'd not gone for a dig to see why 09:32
or even asked you "did you want to know why?"
jnthn Hm, hasn't hung for me in a very long time. 09:34
09:35 brrt` joined 09:41 releasable6 joined, statisfiable6 joined 09:47 travis-ci joined
travis-ci MoarVM build passed. Jonathan Worthington 'Fix missing bounds check in NFA results push 09:47
travis-ci.org/MoarVM/MoarVM/builds/371468806 github.com/MoarVM/MoarVM/compare/e...78b04c0269
09:47 travis-ci left 10:20 ilmari[m] joined 10:24 AlexDaniel joined 10:36 FROGGS joined
lizmat alas, that doesn't solve my "make install" problem :-( 10:38
jnthn OK, it works fine here alas (even tried it a few times just in case) 10:42
lizmat so it must be something in my setup :-(
jnthn Well, or OSX-specific
Could always try and figure out which commit introduced it 10:43
lizmat ok, this gets weird
dd $*REPO; # Use of uninitialized value of type CompUnit::Repository::Staging in string context. 10:44
and the next line is $*REPO.install(...)
and that dies with: No such method 'install' for invocant of type 'Str'
turns out reverting 4120b226b550a485dd fixes it for me 10:51
nine lizmat: then I'd say revert it. The benefit of the commit certainly does not justify that cost 10:52
lizmat indeed, already reverted :-)
samcv: got two errors on nqp's make test: t/nqp/106-unicodenames.t 10:55
samcv: looks like out of sync "<foo>" vs "foo" expectations 10:58
actually, more like "<foo>" vs "FOO"
11:01 wictory[m] joined, AlexDaniel` joined 11:04 brrt joined 11:31 evalable6 joined 11:47 domidumont joined 11:51 domidumont1 joined 12:04 domidumont joined
Geth MoarVM: 0e9418dd36 | (Jonathan Worthington)++ | src/io/asyncsocket.c
Close server socket handle when client side closes

We've so far relied on the user explicitly doing the `close` call, but if they forget, the result is a server where new requests just pile up due to the unclosed handles. Since `.close` is already idempotent (you can call it many times on an async socket handle without problem), we can simply close the handle when notified that the client side has closed without any bad effects on existing code. Meanwhile, code that doesn't bother will simply work. Change inspired by issue reported at
  github.com/rakudo/rakudo/issues/1775.		 12:38
brrt jnthn: my main question wrt to a high-level interface to spesh was going to be, where are we going to run the HLL snippets 12:55
larger, more hairy question; to what extent do we want to reify the VM and it's instrumentation on perl6 level 12:56
jnthn brrt: They aren't run by spesh, they're run in the normal course of execution 12:57
brrt: Spesh just looks at the data that was written 12:58
This isn't really Perl 6 level, it's a VM-specific mechanism we can use when doing code-gen for the MoarVM backend
brrt let me reread, because i'm sure i must have misunderstood 13:00
jnthn D'oh, when the socket IP/port info was added, one of the error paths wasn't updated 13:01
So it didn't pass enough args :(
13:01 domidumont1 joined
brrt ah, i see 13:04
13:04 zakharyas joined
brrt it's a configurable spesh cache 13:05
Geth MoarVM: a7196adc89 | (Jonathan Worthington)++ | src/io/asyncsocket.c
Fix error reporting regression

When sending the connection name/port was added, one of the errors was not updated to pass enough arguments to the callback.		 13:08
jnthn brrt: Pretty much
brrt that seems like it could be handy, yes 13:09
Geth MoarVM: 8a7dcf010c | (Jonathan Worthington)++ | src/io/asyncsocket.c
Root correct object when pushing host/port info

It's `arr` that lives and is referenced beyond this point, not
  `result`.		 13:28
jnthn ah, d'oh, arr is rooted above :/ 13:30
nwc10 is your coffee supply contaminated? 13:31
jnthn Seems like 13:32
Soemthing is going wrong somewhere though...a call to write gets a junk handle
13:44 Kaiepi joined 13:45 domidumont joined
jnthn bah, was hunting a GC bug 13:46
But in the end it was that it was trying to use a type object instead of a concrete handle
Geth MoarVM: 0f55183306 | (Jonathan Worthington)++ | src/io/asyncsocket.c
Remove repeated MVMROOT

The object is already rooted up above.		 13:50
MoarVM: 77e500c62b | (Jonathan Worthington)++ | src/io/io.c
Check we have a concrete OS handle in IO ops
jnthn bah, the coffee really ain't working well today 13:58
nwc10 try the beer?
Geth MoarVM: 717ee970f2 | (Jonathan Worthington)++ | src/io/asyncsocket.c
Push error string argument in the right place
 13:59
jnthn So, with all the silly fixed...now I have a "fun" issue of a spesh guard op being executed when spesh_cand and effective spesh slots are nulled out :S 14:00
Only happens when inlining is enabled 14:13
(gdb) p cur_op - bytecode_start 14:16
$8 = -141721352
Well...that should never happen. o.O
ah, the deopt log ends with a blaze of "JIT: can't find deopt all idx" 14:20
14:23 squashable6 joined
jnthn Though things don't go any better with JIT disabled 14:23
14:28 brrt joined
brrt jnthn: have you tried tools/jit-bisect.pl with the --spesh flag? 14:47
jnthn No, but things are getting stranger. I tried to put in a sanity check that when we return to a frame and it has no spesh cand, return_address is within the bytecode's range. And it fails sometimes...even with spesh disabled o.O 14:48
brrt it's usually pretty good, and it is arguably better with the spesh-limit-debug-log branch 🤓
that is pretty odd indeed
i'm looking at something that i think is also odd... 14:50
timotimo damn, that socket error reporting thing was my mistake, wasn't it ... 14:55
also: not enough spec tests :)
brrt i've wished for a testsuite for the JIT at some point 14:56
dogbert2_ jnthn: are you trying to solve dmaestro's inlining problem? github.com/MoarVM/MoarVM/issues/775
jnthn dogbert2_: No. I got a really weird spesh failure when testing the fixes for the socket issue I was working on earlier 14:57
Then I thought I'd put in some simple debug code to try and catch where things go wrong, and it caught things even with spesh disabled 14:58
So now I'm pretty confused
dogbert2_ oops
jnthn We do 14:59
*(tc->interp_cur_op) = caller->return_address;
*(tc->interp_bytecode_start) = MVM_frame_effective_bytecode(caller);
timotimo :D
that *could* be wrong
jnthn If spesh is disabled then the second function call is always caller->static_info->body.bytecode
And sure there's no way caller->return_address should be outside of the bytecode we're returning in to? 15:00
*surely
timotimo have i recommended rr? :)
you can set hardware watchpoints on these two fields and step backwards to when either of them got changed 15:01
dogbert2_ m: say $*IN.lines.head(250).grep({ / ^ <[ " ]> <[ \w - ]>+ <[ " ]> $ / })».subst( / \" /, "", :g ).elems 15:02
camelia 0
dogbert2_ what piece of code are you running when things go wrong? 15:04
jnthn The simplest code that trips over my sanity check is t/nqp/019-file-ops.t 15:06
gist.github.com/jnthn/f701ad409966...c2925d7850 15:08
That is the added check. I can only hope I'm doing something stupid in it...
In this case the address is *before* the start of the bytecode... 15:09
brrt zero, perchance? 15:10
jnthn (gdb) p caller->return_address - caller->static_info->body.bytecode 15:11
$4 = 1463542
brrt: zero where?
(gdb) p caller->return_address
$1 = (MVMuint8 *) 0x7ffff50c177a "\b"
(gdb) p caller->static_info->body.bytecode
$2 = (MVMuint8 *) 0x7ffff4f5c284 "\214"
brrt that is odd, yes 15:12
jnthn This is with spesh disabled (so, no jitting, no speshing) 15:13
timotimo and no instrumentation either i'm sure
jnthn No, just running directly 15:14
Also this is telling:
at <unknown>:1 (NQPCORE.setting.moarvm:)
from <unknown>:1 (NQPCORE.setting.moarvm:open)
from gen/moar/stage2/NQPCORE.setting:893 (NQPCORE.setting.moarvm:open)
That's a p MVM_dump_backtrace(tc) at that point
Note how the location info is weird 15:15
What's really odd though is...this works o.O
Like, it runs correctly
brrt hmm
timotimo AFK for a little 15:16
brrt so, what if you don't panic, but step into the debugger, and see how the program continues
dogbert2_ jnthn: adding you check causes several tests (nqp) to fail 15:17
MoarVM panic: Caller return address 911160144 bytes after end of bytecode
jnthn brrt: Well, I bp'd it in gdb, but yeah
15:17 harrow joined
jnthn Ah, interestingly the test is 15:19
dies-ok({ open('file_does_not_exist_for_sure', :r);
}, 'open dies on missing file');
So exceptions are involved here also
dogbert2_ add_to_frontier_set, wonder what that is 15:20
jnthn ohhh, maybe the special return mechanism is what makes it right 15:21
Indeed, a different but similar check after that gives me just one NQP test that is unhappy 15:29
ah, and unwinding sets the address explicitly 15:30
jnthn wonders if the failure he now sees tripping the error will be a real issue 15:40
dogbert17 is it a real issue? 16:18
jnthn Dunno, but the SEGV I started out hunting is. And it doesn't trip the sanity check 16:40
16:42 brrt joined 16:48 zakharyas joined
dogbert17 a SEGV, now that's interesting 16:49
16:49 domidumont joined
jnthn Yeah, I really can't figure what's going on :S 16:50
It ends up interpreting specialized code, in a frame with no spesh_cand 16:51
brrt we can sometimes NULL the spesh cand in a deopt, i think
i was looking at that just now
jnthn Sure, but we should always move the bytecode while we do it 16:53
brrt it's might suspicious for sure 16:56
*mighty
jnthn We end up with cur_op pointing at specialized bytecode, and bytecode_start pointing at unspecialized 17:00
And it all seems to happen around exceptions
17:01 zakharyas joined
jnthn Hmm, and the thread where things go wrong does a resume shortly before blowing up 17:04
Yes, the spesh address is precisely the one inside of the exception where we resume 17:07
Ouch.
So the sequence of events is 1. exception thrown, handler runs. 2. exception handler cuases global deopt. 3. exception resume address is now invalid 17:09
Since it points into specialized code
Don't think I've the brain to fix that today, but at least I understand what's going on now, which is half the battle. :) 17:12
bbl & 17:13
17:23 robertle joined 18:54 brrt joined 19:10 zakharyas joined 19:41 brrt joined
jnthn First known to me fallout of the hash randomization change is patched (and actually caused a design improvement): github.com/croservices/cro-http/co...181f218d0c 20:30
dogbert17 m: say ('"WAT"' xx 150).grep({ / ^ <[ " ]> <[ \w - ]>+ <[ " ]> $ / })».subst( / \" /, "", :g ).elems # result should be 150 20:48
camelia 139 20:49
dogbert17 m: say ('"WAT"' xx 150).grep({ / ^ <[ " ]> <[ \w - ]>+ <[ " ]> $ / })».subst( / \" /, "", :g ).elems # result should be 150
camelia 149
dogbert17 m: say ('"WAT"' xx 150).grep({ / ^ <[ " ]> <[ \w - ]>+ <[ " ]> $ / })».subst( / \" /, "", :g ).elems # result should be 150
camelia 146
20:53 brrt joined
dogbert17 in the above case, setting MVM_SPESH_LIMIT=161 seems to resolve the issue on my system 20:57
Geth MoarVM: jstuder-gh++ created pull request #848:
Use operand type in splice jit		 20:59
dogbert17 m: say ('"WAT"' xx 150).grep({ / ^ <[ " ]> <[ \w - ]>+ <[ " ]> $ / }).elems 21:13
camelia 150
dogbert17 m: say ('"WAT"' xx 150).grep({ / ^ <[ " ]> <[ \w - ]>+ <[ " ]> $ / }).elems
camelia 150
dogbert17 m: say ('"WAT"' xx 150).grep({ / ^ <[ " ]> <[ \w - ]>+ <[ " ]> $ / }).elems
camelia 150
dogbert17 the above examples can also fail, so the hyper op seems to be off the hook
Geth MoarVM: 81e6823d6e | (Jeremy Studer)++ | src/jit/graph.c
Use operand type in splice jit

If the operand type is known, have the jit use that type information to select the proper 'splice' implementation. Saves us an extra call to MVM_repr_pos_splice.		 22:25
MoarVM: 6885dbd0d8 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/jit/graph.c
Merge pull request #848 from jstuder-gh/splice_jit_use_type

Use operand type in splice jit
22:58 MasterDuke joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!