03:53 lizmat joined 06:12 vendethiel joined 06:33 FROGGS joined 06:41 vendethiel joined 06:58 Ven joined 07:24 Ven joined 07:41 Ven joined 07:45 vendethiel joined 08:30 Ven joined 08:37 dalek joined 09:12 Ven joined 09:17 zakharyas joined 10:05 vendethiel joined 10:15 Ven joined
jnthn What on earth. A golf of the bug yesterday fails without inlining turned on at all... 10:29
nwc10 by which you mean "still buggy behaviour, but smaller test case"
implying that there's a second bug here, that's unrelated to inlining?
jnthn Seems so 10:30
Yup, I've got it failing with inline and OSR disabled 10:32
But it's been heisen-y enough that I'm somewhat suspecting I'm going to find a memory corruption issue
nwc10 what's the testcase?
ASAN barfs all over (some) naughty code 10:33
jnthn perl6-m --ll-exception -Ilib -e "use Test; for ^2000 { throws-like q[ sub foo(Str) { }; foo 42; ], X::TypeCheck::Argument; }" 10:34
oh heck
//optimize_exception_ops(tc, g, bb, ins);
Commenting those opts out makes it pass
nwc10 ASAN didn't barf 10:38
jnthn And makes the failure I had in spectest go away
Darn
oh, and the non-JIT SEGV comes back when I start enabling some of the opts again 10:40
Well no bloody wonder... 10:42
MVM_ASSIGN_REF(tc, &(o->header), *((MVMObject **)(o + GET_UI16(cur_op, 2))), value);
Where o is an MVMObject *.
So of course you overwrite some bit of memory far far away. 10:43
:/
nwc10 oh, random bug 10:47
unclear me 10:51
oh, bug with really random symptoms
and the culprit will be flogged?
or, more importantly - did the same mistake get made anywhere else?
jnthn The whole lot of work is sloppy 10:52
nwc10 oh, sigh :-(
jnthn The optimization doesn't even seem to check that we *know* it's a proper Exception object
dalek arVM: 0a8cc32 | jnthn++ | src/spesh/codegen.c:
Correct code-gen fixup validation.

Should cover handlers added due to inlining too.		 11:03
arVM: 4fc8c02 | jnthn++ | src/core/interp.c:
Cast to (char *) before adding a number of bytes.
arVM: e0f52cb | jnthn++ | src/spesh/optimize.c:
Disable most of the exception optimizations.

This work was fucking sloppy. Not only were the changes to interp.c bogus, causing random memory overwrites if we ran code in the non-JIT case, not to mention the memory trashing because category is not a 64-bit number, but the optimizations fail to even check that we know we're really digging into something with VMException REPR before rewriting the ops into unchecked memory accesses. All of which led to SEGVs and crashes of all manner.
jnthn aha, and the frame I triangulated yesterday before getting tripped over by the other exception opt faults was in fact the one the JIT seems to be making a meal over 11:19
Hm, and it's nothing very obviously wrong. 11:30
brrt++ # the JIT code is good 11:31
11:44 Ven joined
jnthn Looks like I can fix it with a 1-line adition to the JIT. 11:48
Not the most optimal patch, but I suspect brrt++ might be able to suggest a better one :)
11:54 Ven joined 11:59 zakharyas joined
dalek arVM: f97fd0e | jnthn++ | src/core/exceptions.c:
Scan all handlers when a frame is spesh'd.
 12:07
arVM: 6be8957 | jnthn++ | src/jit/graph.c:
Fix JIT exception handler resolution bug.

After leaving an inline, the "where are we" label could get out of sync, and so we'd fail to find a handler.
arVM: 087314d | jnthn++ | src/spesh/inline.c:
Factor out resizing of handlers table.
arVM: e7a473c | jnthn++ | src/spesh/ (2 files):
Account for inliner's handlers when inlining.

We do this by adding extra entries to the hnadlers table that cover an entire inlinee and go to the handler in the inliner. This means we can still find applicable handlers through a linear scan, so the handler lookup code needs no changes and need not become more complex.
timotimo oh, wow, i botched that branch quite a bit, didn't i 13:21
yes, i really should have asked for a more thorough review 13:22
jnthn I wonder if we need a MVM_SPESH_NODELAY that pulls all the thresholds really low 13:26
timotimo i've considered something like that, and am +1
jnthn So we can builds and spectest spesh changes and have them all apply
Without having to have things that hit the thresholds 13:27
timotimo yes
we must not change the logging thresholds, though?
jnthn True 13:30
timotimo how would i handle the "deprecation cycle" of an sp_ op rename? AFAIK the only places that mention them are inside moarvm itself, so if i rename the sp_bind_i to sp_bind_i64 consistently in moarvm, it'll all work out fine, right? 13:31
jnthn They are completley internal 13:32
timotimo excellent
jnthn So yeah, make everything consistent in the VM and you're good
Unless of course extops with spesh functions refer to them
timotimo since they weren't implemented at all until very recently, i don't think so 13:33
jnthn *nod*
timotimo and i'll put in sp_bind_i* candidates for different integer sizes
but i prefer the naming with numbers over the naming for "quadword", "doubleword", "word" 13:34
FROGGS .oO( Microsoft 16 ) 13:35
13:36 JimmyZ_ joined
timotimo at some point i really have to start grokking MVM_ASSIGN_REF instead of copy-pasting it every time i need it ... 13:39
jnthn Yes, we use the numbers consistently elsewhere 13:40
dalek arVM: 47667f8 | timotimo++ | / (8 files):
introduce sp_bind_i(64|32|16|8) to interp.c
 13:44
arVM: 4f5d0bb | timotimo++ | src/core/interp.c:
fix copy-pasto in sp_bind_n
timotimo i suspect this'll do it
13:46 Ven joined
timotimo added repr id checks into the exception optimizations 13:58
14:06 Ven joined
timotimo i may implement the MVM_SPESH_NODELAY thing right now 14:13
jnthn +1
nwc10 yes, please don't delay 14:14
jnthn Meanwhile I found a code-gen bug for given/when/default that is the source of some of our thread mess-ups
timotimo oh, huh
was there a simple test case that showed the problems with the exception optimizations?
otherwise i'll put in NODELAY and just spec test 14:15
jnthn timotimo: S32-exceptions/misc.t did
And I extracted one of the failing tests and just ran it in a loop
Remember to run with JIT off also 14:16
timotimo i haven't put in jitting for the sp_bind_i{ * < 64 } and sp_get_i{* < 64 } 14:17
so these frames wouldn't get jitted yet
it's probably a good idea to cache the result of MVM_SPESH_NODELAY somewhere 14:19
i'm leaning towards hanging it off the instance
jnthn *nod* 14:20
timotimo it has the spesh log FILE* already, so it's almost topically close by
jnthn And then check it in the function that computes the thresholds
timotimo yup 14:21
already have that up in a window :)
there's also the osr/inline/jit on/off switches
14:23 vendethiel joined
timotimo NODELAY makes segfaults appear everywhere :o 14:30
jnthn o.O 14:32
timotimo well, not *that* bad
jnthn Then I guess we've some spesh bugs to fix.
timotimo gimme a minute
Program received signal SIGSEGV, Segmentation fault. 14:33
MVM_sc_get_object (tc=0x603730, sc=0x0, idx=0) at src/6model/sc.c:160
160 MVMObject **roots = sc->body->root_objects;
i wonder how this happens
at <unknown>:1 (././CORE.setting.moarvm:EXCEPTION:4294967295) 14:35
from <unknown>:1 (././CORE.setting.moarvm::20)
from src/gen/m-CORE.setting:14831 (././CORE.setting.moarvm:throw:0)
could be my mistake in this case :)
jnthn yeah, I'd check what happens with NODELAY without your patches 14:36
timotimo just about to
of course that fixes it :) 14:38
14:48 vendethiel joined 14:53 mtj_ joined
jnthn m: (given 42 { when 42 { say state $a++ } }) xx 10 14:57
camelia rakudo-moar 2aad0b: OUTPUT«0␤0␤0␤0␤0␤0␤0␤0␤0␤0␤»
dalek arVM: 52550f8 | timotimo++ | src/spesh/optimize.c:
properly check repr id in exception optimizations
arVM: 6707601 | timotimo++ | / (8 files):
introduce sp_get_i(64|32|16|8)
arVM: 282d7fa | timotimo++ | src/spesh/optimize.c:
optimize_exception_ops is fragile. comment it out
arVM: bea5d3e | timotimo++ | src/spesh/optimize.c:
... but in theory this is how we'd spesh (get|bind)excategory
timotimo with NODELAY, t/spec/S03-metaops/hyper.rakudo.moar gets This type does not support associative operations 14:58
at src/Perl6/Grammar.nqp:3658 (blib/Perl6/Grammar.moarvm:can_meta:0)
from src/Perl6/Grammar.nqp:3701 (blib/Perl6/Grammar.moarvm:infix_circumfix_meta_operator:sym<« »>:0)
jnthn OK, that's probably aspesh bug 14:59
m: (given 42 { say state $a++ }) xx 10
camelia rakudo-moar 2aad0b: OUTPUT«0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤»
timotimo yes, we do have some bugs left to fix
env MVM_SPESH_NODELAY=1 perl6 t/spec/S09-typed-arrays/native-num.rakudo.moar
MVMArray: bindpos expected num register
in block <unit> at t/spec/S09-typed-arrays/native-num.rakudo.moar:71
jnthn m: (if 42 { say state $a++ }) xx 10 15:00
camelia rakudo-moar 2aad0b: OUTPUT«0␤0␤0␤0␤0␤0␤0␤0␤0␤0␤»
jnthn m: (say state $a++) xx 10
camelia rakudo-moar 2aad0b: OUTPUT«0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤»
JimmyZ_ good catch... 15:03
jnthn I'm not even sure what the right answers are :P 15:04
But something is weird
timotimo is setting the threshold to "5" when NODELAY is set a sensible thing? or should i just set it to 0 or 1? 15:09
jnthn May as well go with 1 15:11
timotimo got it
15:12 lizmat joined
dalek arVM: 181e25b | timotimo++ | src/spesh/threshold.c:
make NODELAY maximum aggressive.
 15:12
timotimo there's even a test in "make test" of rakudo that blows up 15:15
number 99
oooh 15:17
fish: Job 1, “env MVM_SPESH_NODELAY=1 nqp-m t/moar/01-continuations.t” terminated by signal SIGSEGV (Address boundary error)
15:17 oetiker_ joined 15:18 oetiker joined
timotimo "Unimplemented handler action" 15:18
now i have the segfault in gdb
jnthn Is that with or without your patches? 15:19
Uh, your exception ones I mean
timotimo my patches now throw out the exception optimizations (except turning newexception into fastcreate)
all of those are pushed, too
jnthn OK. Need a break; bbiab
timotimo the stack looks completely blown up
i can imagine :S 15:20
15:20 lizmat joined
timotimo without jit, the explosion is actually debuggable 15:21
the argument to decont seems to point at a bogus memory address: gist.github.com/timo/c8f851719105916f70d7 15:23
turning inlining off gives us "Unimplemented handler action" every time instead of segfaulting most of the time and sometimes running to completion 15:28
t/01-sanity/99-test-basic.t segfaults because it tries to call nqp::graphs on a string register that's null'd 15:37
at <unknown>:1 (/home/timo/perl6/install/share/perl6/runtime/./CORE.setting.moarvm:ends-with:4294967295) 15:38
from lib/Test.pm:508 (/home/timo/perl6/install/share/perl6/lib/Test.pm.moarvm::42)
from lib/Test.pm:518 (/home/timo/perl6/install/share/perl6/lib/Test.pm.moarvm:proclaim:424)
from lib/Test.pm:395 (/home/timo/perl6/install/share/perl6/lib/Test.pm.moarvm:eval-lives-ok:74)
the spesh log for that test file is 111 megabytes big with NODELAY 15:46
without NODELAY set, it's only 18 megabytes %)
the final spesh result of the ends-with sub is SO bad 15:54
bind "" to these lexicals, then bind the argument to the lexicals, get the value of the lexical ... 15:55
and then somehow the value ends up being 0x0 ?!?
16:07 vendethiel joined
nwc10 timotimo++ 16:20
ASAN NQP barfage
paste.scsys.co.uk/487594
spectest seems to be barfing, but the output is swallowed by the harness 16:33
timotimo oh, huh 16:36
that's certainly strange
thanks, i'll investigate further 16:37
that is with NODELAY? 16:38
arnsholt jnthn: Would you object to a patch letting the HashAttrStore REPR understand part of the compose protocol, namely box targets and positional/associative delegation? 16:43
Optionally, of course
timotimo so we're return_o-ing into a frame that doesn't point to the right address any more?
JimmyZ_ or gc moves off by one? 16:46
timotimo ?
that would be very weird :D
ah, the free happens practically immediately before the return is done 16:47
MVM_interp_run at :293 causes the candidate_specialize, that frees, then MVM_interp_run:295 stumbles over it 16:48
(hopefully that's correct?)
i don't really know much about the lifecycle of a spesh candidate 16:50
nwc10 timotimo: yes, and 4 more local patches, including disabling the FSA 16:55
timotimo mhm
nwc10 I'm going to try again wiht just 16:56
just this one: paste.scsys.co.uk/487597
16:58 vendethiel joined
timotimo with just a small #ifndef, we could make MVM_FSA_BINS and the other debug things be passed via CFLAGS= for Configure.pl 17:02
nwc10 if that's clean and easy and non-invasive, that seems like a good thing
timotimo it'd look like #ifndef MVM_FSA_BINS #define MVM_FSA_BINS 64 #endif 17:06
nwc10 lots of spectest fail. No easy way to summarise this 17:31
not sure that it's useful to try. Other than to report "this approach seems to be exposing a lot of bugs"
because, I suspect the right thing to do is for whoever-is-going-to-investigate-them to do is to 17:32
1) pick off one
2) fix it
3) retest
and see how many remaining failing tests there are
17:32 JimmyZ_ joined
nwc10 and likely the best one to start with is in the NQP testsuite 17:32
17:48 FROGGS joined
timotimo it could very well be that the code has an assumption inside it that gets blown up by immediately speshing a frame that we've necountered for the very first time? 17:50
though there's the logging in between 17:51
nwc10: can you try again with the latest commit to MoarVM (that touches threshold.c) reverted? 17:56
nwc10 revert 181e25b54bf043715ca207267792d2ae5d3aa126 17:58
... 17:59
t/moar/01-continuations.t still bargs 18:07
18:14 mtj_ joined 18:29 Peter_R joined
jnthn arnsholt: I think such a patch would be fine 18:36
arnsholt: Just be aware that REPR functions can never lead to running user-level code 18:37
19:18 brrt joined
brrt \o 19:20
mea culpa for merging the jit-throw-ops branch before it was ready
i clearly should've reviewed that better 19:21
also, gee, spesh is hard 19:23
jnthn Optimizaiton in general is. :-) 19:24
Especially for langauges that need "sufficiently smart compiler"... :)
brrt waitaminute
call me overeager to correct my earlier dumbness, but why do sp_get_* look like *(type*)((char*)&GET_REG(cur_op, 2) + GET_U16(cur_op, 4)) 19:26
that reads some bytes from the address of GET_REG(cur_op, 2) 19:27
not from the pointer in GET_REG(cur_op,2)
or
why is that & there
19:27 lizmat joined
jnthn brrt: That looks...odd. Especially as it probably wants to (char *) an access to a .o 19:28
brrt i think i'm find with casting to (char*) to get the address. but not with getting the address relative to the register 19:30
jnthn Right, the register should contain an address
Maybe that's why stuff was still busted
brrt let's change it 19:31
dalek arVM: 94fdbca | brrt++ | src/core/interp.c:
sp_get_* must take address relative to object

rather than relative to register		 19:36
brrt ok, i'll be off now 19:39
jnthn o/
brrt see you :-)
19:40 travis-ci joined
travis-ci MoarVM build failed. Bart Wiegmans 'sp_get_* must take address relative to object 19:40
travis-ci.org/MoarVM/MoarVM/builds/66104438 github.com/MoarVM/MoarVM/compare/1...fdbca3b44a
19:40 travis-ci left
jnthn rt.perl.org/Ticket/Update.html?id=125331 is a bizzare one; turns out it gives a differrent error while we're recording a spesh log, and then goes back to the correct error afterwards o.O 19:43
nwc10 oh gnoes. it's now sufficiently un-C that even gcc doesn't like it. 19:45
jnthn uh yes, that probably wanted a .o on the end
nwc10 a language not entirely unlike C 19:46
jnthn Which is accepted by...some compiler :)
nwc10 nutrimatiC 19:47
jnthn OK, this bug is nuts. wtf. 19:53
nwc10 go eat?
jnthn :P 19:54
jnthn already cooked/ate a huge plate of pasta with saussage earlier :) 19:55
nwc10 beer? 19:56
sleep?
jnthn ah...I bet it's that we get bytecode annotations messed up in the backtrac 19:59
*backtrace
Well, that's a tricky enough problem that I ain't going to come up with a good solution tonight. At least I understand I'd better solve it ) 20:08
*:)
nwc10 are you able to fix brrt's barf?
jnthn
.oO( brrf )
 20:09
yes, looking now
nwc10 cool, thanks
jnthn Geez, the thing clang will accept as C :P
nwc10 it took the "sloppy is better" approach of gcc, and doubled up? 20:10
jnthn MSVC rules with an iron C89
nwc10 big iron vendor Unix C compilers are usually pretty good at catching sloppy stuff 20:11
or "unforgiving"
dalek arVM: 81cfb4d | jnthn++ | src/core/interp.c:
Fix the build for grown-up C compilers.
 20:13
jnthn "You clang kids can get off my lawn!" :P
nwc10 pass
jnthn yay
nwc10 how long will travis take
jnthn O(minutes) I guess 20:14
20:23 travis-ci joined
travis-ci MoarVM build passed. Jonathan Worthington 'Fix the build for grown-up C compilers.' 20:23
travis-ci.org/MoarVM/MoarVM/builds/66110162 github.com/MoarVM/MoarVM/compare/9...cfb4deaadc
20:23 travis-ci left
nwc10 O(yes) 20:29
arnsholt jnthn: Yeah, running user-level code wasn't my intention 20:39
Basically something like the P6opaque REPR, where an attribute is designated to handle something
timotimo wow, i made more mistakes than i'd've thought
(sp_get_*) 20:40
arnsholt Which would make my life a little easier when implementing lists and hashes for Snake: the objects can be HashAttrStore (although I may move some things to P6opaque at some point), but still be able to handle nqp::atpos and friends
timotimo fish: Job 1, “env MVM_SPESH_NODELAY=1 ./nqp-m t/moar/01-continuations.t” terminated by signal SIGILL (Illegal instruction) 20:46
wow.
fish: Job 1, “env MVM_SPESH_NODELAY=1 ./nqp-m t/moar/01-continuations.t” terminated by signal SIGBUS (Misaligned address error) 20:47
all the cool errors
well, it comes from jumping into free'd memory with the instruction pointer
just by increasing the threshold to 2 instead of 1, we get "unimplemented handler action" nistead of brokenness 20:49
so maybe that's the proper fix here?
hum. it doesn't fix the seg fault in NativeCall.pm 21:09
jnthn timotimo: I doubt that's a proper fix, I suspect it just changes the failure mode 21:10
timotimo mhm 21:12
jnthn 'night o/
timotimo in NativeCall's compilation it tries to fetch from a container spec whose fetch is fetch = 0x48002800000001, 21:13
kind of weird to have a 1 at the end there
gnite jnthn
maybe we're doing decont on something that can decont_i or so? 21:16
21:35 vendethiel- joined 21:45 lizmat joined 22:37 vendethiel 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!