01:00 jnap joined 01:20 FROGGS_ joined 01:59 vendethiel joined 07:39 brrt joined
brrt it's possible a decont is missing, yes, but that would imply a spesh bug rather than a jit bug 07:42
FROGGS_ I don't believe in a GC bug btw 07:45
brrt me neither, anymore 07:46
fwiw, i never believed that is was a GC bug per se, just that it could be a bug in how i'd hit write barriers 07:47
ren1us it seems like moar is allocating more memory as it needs it, which is fine, but does it (or rather, should it) release that memory back to the system as soon as it no longer needs so much? 08:42
brrt i'm not very sure about that, that'd typically need a page-based allocator, and i don't think that's what moarvm does 08:43
i.e. i /think/ it leans on malloc
ren1us i've been trying to golf down what i believed to be a memory leak, and i just notice that memory never goes down, even if my high memory things fall out of scope 08:45
brrt that's basically how malloc works (in my memory, don't know it exactly)
ren1us then again i see no reason why it should be getting to over a gig of memory in the first place. i blame 'is copy'
08:51 lizmat joined 08:53 woolfy joined
dalek arVM/moar-jit: c97ca8b | (Bart Wiegmans)++ | src/jit/ (4 files):
Add a few ops
 09:14
arVM/moar-jit: 47f6848 | (Bart Wiegmans)++ | src/ (4 files):
Add boxing operators

For simplicity, this means I moved the conditional initialization of a container to a function in coerce.c. This should make the non-jitted times somewhat slower, however I feel that'd be an acceptable compromise.
arVM/moar-jit: 60275ae | (Bart Wiegmans)++ | src/ (6 files):
Added istrue (is invokish) and isnull_s
 09:46
brrt yay, heap corruption detected 09:47
seems like we're getting somewhere
FROGGS_ \o/ 09:48
brrt .. or not
still happens with MVM_JIT_DISABLE=1 09:49
:'-(
speshbug 09:50
great
FROGGS_ yeah
brrt not even a spesh bug 09:52
just a bug
*ugh* 09:54
brrt will check it out after lunch
09:54 brrt left 10:32 brrt joined
brrt ok, it's my bug in the wrapped boxing operators 10:33
FROGGS_ ohh, that sounds like progress!
brrt it's progress, but not in the same bux 10:36
bug
FROGGS_ but still, progress :o) 10:37
brrt :-)
.... 10:59
for some reason that NOBODY WANTS TO KNOW ABOUT, boxing strings is just ... illegal 11:00
that is to say, it's illegal if it's done in a function, and it's not illegal if it is done within the interpreter runloop 11:01
wtf
wtf wtf wtf wtf 11:06
nqp_nfa_run... where's that 11:07
and, is it new?
why.... is any of this broken 11:09
it just doesn't make sense
it's a heap corruption, that's for sure
timotimo nfa_run is what handles the regex stuff that the NFA generator builds 11:11
brrt it's not that... which is broken 11:17
what's broken is somehow memory is corrupted
and i'm clueless as to why
timotimo yikes! :(
dalek arVM/moar-jit: d1b271a | (Bart Wiegmans)++ | src/ (4 files):
MVM_box_str causes heap corruption, no idea why
 11:29
FROGGS_ It think the value in here should have been MVMROOTed before allocating: github.com/MoarVM/MoarVM/commit/47...6f2eedR405 11:34
(coerce.c line 405 on this page)
and I don't think you need to MVMROOT box at all 11:39
brrt hmm 11:49
ok, i'll see if that changes anything
FROGGS_ I bet it will
I'm pretty sure that I am right *g*
brrt i very much hope so
so you advise to a): remove the whole MVMRoot thing B): move allocating in MVMRoot? 11:50
ok, i don't know what you mean, i'm sorry :-) 11:51
FROGGS_ you only need to MVMROOT the value for box_s, and then move the alloc within that MVMROOT
so you protect the value while you are allocating 11:52
and since the other boxing function have numeric values, no MVMROOT is needed
brrt o rly
well
let's do that then
FROGGS_ only in the code that calls these functions of course, in case a pointer is obtained that is still used after the call to box_* 11:53
brrt you're absolutely correct; i still don't get it 11:54
why shouldn't the box be MVMROOT'ed
(it fixes it :-))
FROGGS_ because as long as you use box, nothing allocates
and therefor the GC is not running so the pointer box still points to the right thing 11:55
brrt may initialize not allocate?
FROGGS_ look at what it does 11:56
usually it just sets values to previously allocated space
otherwise it would be over complex
brrt you're quite right 11:57
FROGGS_ though note, this like creating an MVMString from a C string allocates too of course
things like*
11:57 carlin joined
brrt still doesn't understand why moving it from the interpreter to the function caused the crash] 11:57
FROGGS_ where do you call that function? 11:58
brrt github.com/MoarVM/MoarVM/commit/47...05f0fR2336 here 12:00
in interp.c
dalek arVM/moar-jit: c879b64 | (Bart Wiegmans)++ | src/core/ (2 files):
Fixed issue with box_i thanks to FROGGS++
 12:07
brrt well, thanks
dunno why this helps, but thanks anyway :-)
hmm maybe i do understand why it helps, but that means - it seems - that the code in interp.c was just Wrong 12:10
so that... at least causes a SEGV when run in the JIT 12:19
but it runs well without JIT
bbiab 12:20
FROGGS_ hmmm, I really don't see the need for the MVMROOT in box_i in interp.c:2338 in moar/master... 12:22
12:25 jnap joined 13:13 brrt joined
brrt FROGGS_: it isn't actually necessary, it seems 13:14
FROGGS_ yeah, and the MVMROOT in box_s is indeed wrong... the GET_REG(cur_op, 2).s needs to be MVMROOTed 14:00
I see other ops that do that
.tell jnthn Is that a valid patch about rooting? gist.github.com/FROGGS/534f320aa548e12f75c4 14:08
14:13 zakharyas joined 14:31 brrt joined
brrt lgtm :-) 15:58
basically, it'd be even better to merge it with the functions in moar-jit :-) 15:59
16:12 btyler joined 17:41 brrt joined
brrt hmm, how do i get a null value for a string? 17:56
FROGGS_ brrt: sure, this would also avoid a conflict in git...
what do you mean by null value? 17:57
brrt as in, a null pointer string
(strings may be null)
FROGGS_ hmmmm, I remember something... 18:00
right, there is even an nqp::isnull_s op
and there is a null_s op 18:01
brrt i've got it, thanks :-) 18:03
ok, and how do i repeat a string? 18:07
FROGGS_ nqp-m: say(nqp::xx("foo", 3)) 18:11
camelia nqp-moarvm: OUTPUT«Error while compiling op xx (source text: "nqp::xx(\"foo\", 3)"): No registered operation handler for 'xx'␤ at gen/moar/stage2/QAST.nqp:4789 (/home/p6eval/rakudo-inst-2/languages/nqp/lib/QAST.moarvm:as_mast:72)␤ from gen/moar/stage2/QAST.nqp:4111 (/home/p6…»
FROGGS_ nqp-m: say(nqp::x("foo", 3))
camelia nqp-moarvm: OUTPUT«foofoofoo␤»
FROGGS_ brrt: ^^
brrt aahaaaah
:-)
FROGGS_ that's the speshbug I get in S02-magicals/args.t: postcircumfix:<{ }> binding not defined for type Hash 18:22
brrt huh 18:23
FROGGS_ a lot of test files fail that way btw 18:27
ohh, Test::Util triggers it... 18:31
ummm, it still fails that way, but Test::Util is empty now 18:37
O.o
brrt is there any way i can find out (for a static frame) what file it came from? 18:50
oh, the CompUnit
FROGGS_ I guess the backtrace printing function might be a good place to copy from 18:51
brrt well, it is, thanks :-) 18:55
FROGGS_ I sometimes just conditionally call it to dump out my current call chain 18:56
and this is where my speshbug happens btw: github.com/rakudo/rakudo/blob/nom/...ile.pm#L62 18:57
19:05 zakharyas joined
FROGGS_ spectest passes when I turn the binding to an assignment 19:10
now, how do I track this thing down?
it only fails in spectests :/
20:33 tgt 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!