github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM/postrelease-opts: cc3a17414b | (Jonathan Worthington)++ | src/jit/x64/emit.dasc
Fix JIT of specialized bigint ops

In the case where the result was going into the same register that an input argument came from, we stored the result prematurely, and then read a NULLed out bigint struct as one of the arguments. This only took place in the fallback path and when the earlier requirement was meant. Fixes various crashing spectests.		 00:01
MoarVM/postrelease-opts: 40f8a8ba85 | (Jonathan Worthington)++ | src/6model/reprs/P6bigint.c
Correct indentation
jnthn Sadly, while that fixes spectests, it doesn't fix the CORE.setting SEGV. That'll have to wait for another day. 00:04
Also, it looks like it stands a good chance of having fixed all the unhappy spectests, which means I may really be left with using CORE.setting compilation as the problem example. 00:05
'ngiht
timotimo gnite jnthn 00:07
the "promoted/cleared/retained bytes" graph looks very funny when the second gc run has 1000x as much in total as all other bars ... by which i mean there's just a single peak and nothing else :D 00:28
m: say 4294966848.base(16) 00:44
camelia FFFFFE40
timotimo huh, i wonder if this was actually a negative value
chrome devtools be like "hey, i need all of your CPU for as long as i'm displaying nothing, K? 00:46
maybe it was connected to how the log was shaking
00:50 squashable6 joined, p6bannerbot sets mode: +v squashable6
timotimo ho-hum, the reflog just saved me from losing the code that recorded the type information in the profiler 00:54
01:00 lizmat joined 01:01 p6bannerbot sets mode: +v lizmat 01:10 lizmat left 02:29 wictory[m] left, AlexDaniel` left, timotimo left 02:35 wictory[m] joined, p6bannerbot sets mode: +v wictory[m] 02:37 timotimo joined, p6bannerbot sets mode: +v timotimo 02:38 AlexDaniel` joined, p6bannerbot sets mode: +v AlexDaniel` 04:20 ggoebel left 04:34 ggoebel joined 04:35 p6bannerbot sets mode: +v ggoebel 06:47 pmn joined 06:55 MasterDuke left 06:56 pmn left 07:07 fake_space_whale left 07:49 domidumont joined 07:50 p6bannerbot sets mode: +v domidumont 08:01 zakharyas joined 08:02 p6bannerbot sets mode: +v zakharyas 08:12 domidumont left 08:41 tktech7 joined 08:43 tktech7 left 08:44 lizmat joined 08:45 p6bannerbot sets mode: +v lizmat 09:01 lizmat left 09:08 lizmat joined 09:09 p6bannerbot sets mode: +v lizmat
Geth MoarVM: c43a9b97e1 | (Jeremy Studer)++ | .travis.yml
Workaround version failure on Travis CI (MacOS)

Travis doesn't fetch the full history (only 50 commits by default) and we use 'git fetch --unshallow' to retrieve the rest. This is necessary to retrieve the tags used in versioning MoarVM. That process does not appear to be working on MacOS currently.
Explicitly fetch the full history in order to work around this defect.
  See [this thread](github.com/travis-ci/travis-ci/issues/4942)
for more information.		 09:17
MoarVM: 99ddb9d4a4 | (Jeremy Studer)++ | .travis.yml
Remove unshallow as it causes error on full repo
MoarVM: e530be4d35 | (Jonathan Worthington)++ (committed using GitHub Web editor) | .travis.yml
Merge pull request #945 from jstuder-gh/travis_tags_mac_os

Workaround version failure on Travis CI (MacOS)
09:36 lizmat_ joined 09:37 p6bannerbot sets mode: +v lizmat_ 09:39 lizmat left
AlexDaniel jnthn: fwiw you can click `Edit` on a PR and change `base:master` to another branch 09:41
this way you can merge it to, say, postrelease-opts
09:47 stmuk joined 09:48 p6bannerbot sets mode: +v stmuk
jnthn AlexDaniel: I could, but I've already got a nasty bug to track down in that, and would rather not have another variable factor. 09:49
AlexDaniel ok sure
09:50 stmuk_ left
jnthn I plan to (once I've fixed the nasty remaining issue I know about) merge postrelease-opts soon after the release 09:50
If it's possible to get a toaster run of that, it'd be cool, since I'll have time next week to fix things up, but not much time at all for MoarVM/Rakudo things in the 2 weeks after. 09:51
AlexDaniel I see
jnthn Ideally there'll be no regressions from it, but...shiny new opts don't always work out that way. 09:53
AlexDaniel hmmm but that just means that we should toast it before merging 09:54
jnthn: so, as far as I understand, to toast it we'd need a branch in nqp and rakudo with appropriate *_REVISION files 09:55
and that's it 09:56
10:10 domidumont joined 10:11 p6bannerbot sets mode: +v domidumont
jnthn That'd also be an option, yes 10:14
With the downside that we delay finding stuff that users following HEAD testing it might also find 10:15
10:17 lizmat_ is now known as lizmat
dogbert17 are we still looking for the setting SEGV? 10:21
jnthn: I guess you already know but if not, the SEGV occurs here: github.com/MoarVM/MoarVM/blob/post...rp.c#L2062 10:24
jnthn Yeah, and it's a null pointer exception. But that tells us approximately nothing about where the real problem is. 10:25
dogbert17 so you need something short and sweet, 100% reproducible? 10:26
jnthn I tried getting the same issue out of the spectests, but at least with MVM_SPESH_BLOCKING=1 all the things that broke seemed to be fixed by what I did last night 10:28
dogbert17 I got two failures during spectest (t/spec/S06-other/anon-hashes-vs-blocks.t and t/spec/S12-methods/private.t) but trying to repro failed 10:29
I could see that no tests were run so they failed early
jnthn: t/09-moar/00-misc.t seems like a good file to run, fails consistently for me 10:45
jnthn That's only because the branch misses a fix from master 10:46
dogbert17 :( 10:47
damn
lizmat t/spec/MISC/misc-6.d.t flaps for me, but probably has nothing to do with this 10:54
test 3: native num defaults to 0e0
dogbert17 jnthn: is it the 'Fix race in setting the type debug name' commit
lizmat: I've had that 0e0 test flap several times 10:55
jnthn dogbert17: yes 10:56
dogbert17 thx
11:07 undersightable6 joined, p6bannerbot sets mode: +v undersightable6
dogbert17 hmm, I cherry picked the fix from master and the error in t/09-moar/00-misc.t disappeared but now I get a consistent fail in t/spec/integration/weird-errors.t 11:09
perhaps that's not the correct way of doing things ... 11:11
jnthn: take a glance at gist.github.com/dogbert17/4b2bc72a...505c44e7de time permitting 11:18
11:23 zakharyas left 11:38 lizmat left
jnthn I probably *should* work on something else, but will debug this a bit. ) 12:06
Gonna rebase postrelease-opts on master 12:08
dogbert17: Hm, also interesting 12:14
Wonder if I can get ASAN to complain about that
Good news is that I can reliably repro the CORE.setting optimize stage crash at the office too 12:15
And my machine here is at least quite a bit faster than at home
aha, it just did a deopt in optimize_p6typecheckrv and that's the frame we're in when we crash 12:17
Deopt one requested by JIT in frame 'optimize_p6typecheckrv' (cuid '65') (4294967295 -> 42)
m: say 4294967295.base(16) 12:18
camelia FFFFFFFF
jnthn Hmmmm.
Only happens when running under the JIT too 12:31
dogbert17 jnthn: I updated gist.github.com/dogbert17/4b2bc72a...505c44e7de with ASAN output 12:35
jnthn This makes little sense: 12:36
[Annotation: INS Deopt Inline (idx 25 -> pc 104; line 1521)]
[Annotation: INS Deopt Inline (idx 22 -> pc 48; line 1521)]
sp_guardtype r22(2), r22(1), sslot(7), litui32(42)
dogbert17: Thanks, interesting. 12:43
12:45 zakharyas joined, p6bannerbot sets mode: +v zakharyas
Geth MoarVM/postrelease-opts: 53 commits pushed by (Jonathan Worthington)++, (Timo Paulssen)++, MasterDuke17++
review: github.com/MoarVM/MoarVM/compare/4...aa26882a40		 13:00
jnthn that's the rebase
Testing a fix for the CORE.setting SEGV 13:01
Another of those bugs we had, but only just exposed 13:02
dogbert17 cool, so you might have found it 13:03
jnthn Think so
Doubt it fixes the other issue though
dogbert17 which is still present after the rebase
jnthn Yeah, make test should be clean though 13:04
It's good with my latest fix too 13:05
make spectest now
with spesh blocking on
nwc10 that was the one that I reported? 13:06
jnthn nwc10: CORE.setting crash at stage optimize with null pointer deref?
nwc10 no, MVM_SPESH_NODELAY=1 IIRC caused a setting compilation abort with some sort of error diagnistic 13:07
IIRC
jnthn ah
No, didn't try it what that
nwc10 or was it the other variable
jnthn OK, weird-errors.t is the only spectset fail I have left with spesh_blocking 13:08
dogbert17 that's sounds like a good result 13:09
Geth MoarVM/postrelease-opts: 58926538d8 | (Jonathan Worthington)++ | src/spesh/codegen.c
Populate all deopt points with an offset

Rather than just the first one of each kind that we encounter. With more aggressive optimizations, we could end up with multiple of them being shuffled onto the same instruction.		 13:10
jnthn And yeah, the weird-errors one is...weird :)
It's a bugger overflow
dogbert17 :)
jnthn uhh
*buffer
In a bit of code that didn't change for ages, and that I can't see much to go wrong with... :S 13:11
The way it typically blows up is at free of the thing we went over the end of 13:12
But ASAN nicely catches it earlier
dogbert17 ASAN++ 13:13
MVM_SPESH_INLINE_DISABLE=1 makes it vanish
jnthn oh, hmm
(gdb) p cand->handlers[0] 13:39
$3 = {start_offset = 60, end_offset = 54, 13:40
umm :)
dogbert17 that looks slightly wrong :) 13:43
jnthn tests a fix 13:47
dogbert17 dashes out to buy some fikabrƶd 13:49
jnthn ooh yes, it's almost cookie o'clock... 13:51
Woo, clean spectest with MVM_SPESH_BLOCKING 13:54
Geth MoarVM/postrelease-opts: 24d98c64a5 | (Jonathan Worthington)++ | src/spesh/graph.c
Consider handler with start > end unreachable
MoarVM/postrelease-opts: e2fe88f9db | (Jonathan Worthington)++ | src/spesh/graph.c
Harden against handler start/end on same ins

We could potentially process the start after the end in this case, and so leave inconsistent data in the active handlers data array.
dogbert17 jnthn++ 13:56
jnthn NQP is happy with NODELAY too, both build and tests
Waiting for Rakudo build with that now 13:57
Currently doing CORE.setting
yay, it builds CORE.setting fine too 13:58
dogbert17 hooray
jnthn Gets through the whole Rakudo build. Now for make test
Ah, that's less good :/ 13:59
dogbert17 nooo 14:00
nwc10 pavent pizza? 14:03
pavement
jnthn Lots of fails, but all looking to have one root cause 14:04
(Module loading gets broked)
nwc10 "insufficient cookies"?
ilmari ooh, that reminds me, office snacktime! 14:05
(yes, I have had lunch)
nwc10 and the london.pm social?
ilmari++ 14:06
ilmari gah, I forgot, it's in the other building on thursdays 14:13
nwc10 does this make it acceptable to nip out for a swift pint instead? 14:14
"no, not on a logged channel"
14:15 brrt joined 14:16 p6bannerbot sets mode: +v brrt
ilmari I already had lunch... 14:16
brrt \o
nwc10 o/
14:56 brrt left, brrt joined 14:57 CoJaBo13 joined, p6bannerbot sets mode: +v brrt 14:58 CoJaBo13 left 15:03 fake_space_whale joined 15:04 p6bannerbot sets mode: +v fake_space_whale
jnthn Grr, so I was like "oh wow, getdynlex would never work if inlined!" and "fixed" that...then discovered that it was marked :noinline 15:21
I didn't fix the problem I'm hunting, but it seems I accidentally implemented an optimization :P 15:22
[Coke] a pleasant oops. 15:25
jnthn Hm, actually it won't work :) 15:26
I think it may genuinely be a fix though.
But still not for my bug :P
Ah, I think I found my one 15:30
Inlining loadbytecode goes badly 15:31
And I can see why too 15:32
We don't recognize it as an invoke 15:33
dogbert17 I hope you didn't miss cookie time :) 15:36
jnthn I didn't, but I ate all the cookies and now have none left for tomorrow 15:37
TimToady still thinks occasionally about the idea of storing an authoritative dynvar cache only in frames that add a dynvar, and just carrying a link to the nearest one
brrt had another idea which I wanted to annoy you with 15:38
see, from my understanding, dynamic variables in perl5 are implemented as globals, and when localized, the compiler inserts a swap-to-and-from 15:39
or the interpreter executes them, I don't know and it doesn't matter
TimToady we abandoned that on purpose
brrt what was the purpose
Geth MoarVM/postrelease-opts: c20d5112f0 | (Jonathan Worthington)++ | src/jit/x64/emit.dasc
Bring JIT of getlexreldyn in line with interp
MoarVM/postrelease-opts: 8063990bc4 | (Jonathan Worthington)++ | 2 files
Do not inline loadbytecode

It makes various invocations, and we don't end up with the calling point properly tracked as a deopt point, in turn breaking things like dynamic variable resolutions very close to the point that did the loadbytecode.
TimToady make them thread-safer, for one
brrt because that is a very efficient way to implement them
TimToady and avoid globals
brrt bind them to a threadcontext, and they're thread safe 15:40
(rather than to the global instance)
timotimo except when you resolve the dyn vars that were active when you "start"ed a piece of code
and it runs on another thread :)
jnthn Who wants to write the fixup code when a continuation migrates thread? :)
timotimo moarvm will write it for us!
jnthn But also, whatever happens need to deal with inlining
timotimo so we just need someone to write the code that writes the fixup code
jnthn Because what happens if you inline a frame that declares dynamic variables? 15:41
Then some of the cache is only applicable for part of the frame
brrt the push-and-pop become part of the inlined code
jnthn Not saying it ain't possible, just that this all has to be thought about 15:42
TimToady it's also just terribly fragile without strict RAII, which p5 has
brrt also, the fixup for continuations isn't so hard, I think? we swap the pointer to the table?
thing is, we do have that, in terms of special-return
jnthn So with the above commits we're back to `make test` in Rakudo being happy under NODELAY :) 15:43
brrt \o/
TimToady anyway, we have "temp" if you want it, which does that already 15:44
brrt hmmm
jnthn spectset has a little unhappiness 15:46
As in, "a little more than the amount we tend to tolerate" :)
TimToady
.oO(Better red than dead?)
 15:47
dogbert17 any test file in particular?
jnthn dogbert17: The one I looked at was int-unit
15:48 brrt left
dogbert17 and I got a fail, before applying your latest fix, in t/spec/S32-hash/antipairs.t 15:48
ah, a classic which timotimo will recognize 15:49
0x00007ffff765fb24 in MVM_gc_mark_collectable (tc=0x604a70, worklist=0x356ced0, new_addr=0x365f4a8) at src/gc/collect.c:370
370 MVM_gc_worklist_add(tc, worklist, &(tc->instance->all_scs[sc_idx]->sc));
where sc_idx contains a bogus value 15:51
TimToady anyway, we could replace the currently cached dyn value in the frame with a direct pointer to the next cache to look at without growing the frame
the only cost is an extra data structure on frames that declare a dynvar
and could just use the same pointer, with a flag saying it belongs to us 15:52
jnthn One problem (that we probably need to solve anyway) is that the VM currently doesn't understand which lexicals are dynamic or not (in terms of declaration; the lookup is carried with the op)
TimToady presumably we could cache negative lookup results as well, which is what I mean by authoritative 15:53
right, and the whole $_ problem you were talking about the other day
I'm fine with tweaking the language to make everything faster :)
jnthn Was about to ask about that one :) 15:54
TimToady where "tweak" probably excludes throwing out the containers ;) 15:55
TimToady actually backlogged the three weeks he was out of touch, thanks to a newly-written log colerizer that helped his poor eyes skim better 15:56
dogbert17 so there seems to be 'one' bug left to find 16:05
jnthn haha...if only :P 16:06
TimToady That's an off-by-āˆž/1 error? 16:08
jnthn Some days, it feels like it :P
OK, lots of the NODELAY spectest fails are fixed 16:21
need to look at the results of the latest run but I suspect there'll be one remaining thing I should really look at
dogbert17 and what might that be? 16:24
nwc10 stock levels in the cookie jar? or the beer fridge?
Geth MoarVM/postrelease-opts: 9a6adf2612 | (Jonathan Worthington)++ | 3 files
Make forceouterctx more forgiving

  * Try going for an outer frame if the immediately available one is
   inlined (this will work together with a change in Rakudo to mark
   frames that use `EVAL` as no-inline, and mean that `try EVAL $x`
   will work out fine)
  * If that doesn't work, don't SEGV, but throw		 16:25
jnthn dogbert17: A couple blow up with "MoarVM panic: Spesh codegen: out of range BB index 108" 16:28
dogbert17 aha, haven't seen those 16:29
does this give you any ideas? gist.github.com/dogbert17/47efe57d...cd809ec4da
jnthn t/spec/S04-declarations/constant-6.d.t does it
dogbert17: I've no clue what that one would be 16:30
dogbert17 darn
note that I had small nursery + MVM_GC_DEBUG set there 16:31
16:33 fake_space_whale left
jnthn Above blow-up is something wrong with merge_bbs 16:36
dogbert17 would be nice if ASAN could help out here 16:41
jnthn Well, it's a panic due to a malformed graph
goto BB(108)
Successors: 108, 80
That goto should really be to BB(80) 16:42
dogbert17 have you managed to repro?
jnthn Oh yeah, it's very stable
Happens every time
dogbert17 as good as it gets then :) 16:43
jnthn And if I comment out the call to merge_bbs then it goes away
dogbert17 ah
jnthn hm, and I moved the call to that a bit later 16:44
Geth MoarVM/postrelease-opts: 544ee885aa | (Jonathan Worthington)++ | src/spesh/optimize.c
Revert "Do basic block merging as the last step"

This reverts commit d84778a0f9958d89b3bb61855e2aed69ad48be6a, which caused some breakage. Also, it might well have been better placed (or at least just as well placed) beforehand anyway.		 16:45
dogbert17 oops, a revert 16:47
jnthn That helps :)
I'm not convinced it was an improvemnet to move it anyway 16:48
That'll fix 2 more. Then there's t/spec/S32-num/expmod.rakudo.moar left, which is a SEGV under the JIT
dogbert17 is that with MVM_SPESH_NODELAY=1 ? 16:49
jnthn Yup
And blocking
dogbert17 ok 16:50
jnthn Hm, commenting out JIT of the various new bigint ops still gets me a fail, even though it's in that area 16:51
dogbert17 0 0x00007f100f4869e7 in get_bigint_body (obj=0x40b28b8, tc=0xe0fa70) at src/math/bigintops.c:148
148 return (MVMP6bigintBody *)REPR(obj)->box_funcs.get_boxed_ref(tc,
jnthn Yeah, same as I see
ah, not me :) 16:52
It's an expr jit sensitive one 16:53
I suspect this occurs on master too, then
dogbert17 running under valgrind uncovers
an invalid read so not much new there, was the same line 16:54
aha it vanishes, for me, with MVM_JIT_EXPR_DISABLE=1 16:55
jnthn yup; I'm guessing there's a bug in the template 16:56
16:56 japhb left
dogbert17 something for brrt perhaps 16:57
don't forget dinner 17:01
17:01 slackjeff joined 17:02 zakharyas left
jnthn heh, I found a way to make it give all the wrong answers instead of segfault :) 17:04
17:04 slackjeff left 17:05 zakharyas joined, p6bannerbot sets mode: +v zakharyas
jnthn oh, I also found a way that works 17:06
I don't understand *why*
:)
17:08 japhb joined 17:09 p6bannerbot sets mode: +v japhb
Geth MoarVM/postrelease-opts: db0e310c36 | (Jonathan Worthington)++ | src/jit/core_templates.expr
Fix expmod_I template

Or at least, change it so it works. My gut feeling is that the way it was before should produce better code (doesn't need to save a value during a call), and that the change I've done should have had no semantic effect.		 17:11
jnthn .tell brrt github.com/MoarVM/MoarVM/commit/db0e310c36 makes `MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1 ./perl6-m t/spec/S32-num/expmod.rakudo.moar` pass (before that commit it was SEGV), but I'm not sure why. :) 17:12
yoleaux jnthn: I'll pass your message to brrt.
dogbert17 impressive
jnthn Confusing :) 17:13
But either I learn something or we found an expr jit bug
17:13 badon20 joined
jnthn Darn, it was too hot to sleep with a blanket and I've ended up with a bunch of insect bites, all of which itch :/ 17:14
But...
dogbert17 is it still hot
17:14 p6bannerbot sets mode: +v badon20
jnthn Today is probably the last day of too hot weather! 17:14
Yes, 33C
dogbert17 gah, that's way too much 17:15
jnthn Indeed.
It's been 4+ weeks of mostly way too hot
17:15 badon20 left
jnthn But it should finally improve from tomorrow, and next week looks like mid-20s at the very most 17:15
dogbert17 that's definitely more comfortable
[Coke] (too hot) I am a bad human and use too much AC 17:16
jnthn If I had AC I'd use it too :P 17:17
Prague's weather isn't supposed to be like this
Though I fear it's the new normal
Given that every year since I've been here has been above average
Things look rather better with today's fixes :) 17:18
dogbert17 indeed, is mergeable, after the release ofc?
*is it
[Coke] deliberately misreads that as "Prague's weather looks rather better with today's fixes" 17:20
jnthn That fix is still to come (thunderstorm :)) 17:27
OK, enough for now :) 17:28
And tomorrow I really had better work on all the things I was meant to do today :P 17:29
bbl o/ 17:30
[Coke] jnthn: I feel like you have described my $DAYJOB this week. 17:31
18:49 lizmat joined, brrt joined, p6bannerbot sets mode: +v lizmat 18:50 p6bannerbot sets mode: +v brrt
brrt \o 18:50
yoleaux 17:12Z <jnthn> brrt: github.com/MoarVM/MoarVM/commit/db0e310c36 makes `MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1 ./perl6-m t/spec/S32-num/expmod.rakudo.moar` pass (before that commit it was SEGV), but I'm not sure why. :)
brrt well, fortunately I do
jnthn Ah, good :) 18:54
Well, depending on the explanation :P
18:54 zakharyas left
brrt left a note on the commit 19:00
github.com/MoarVM/MoarVM/commit/db...#r30270684
(I love how nearly everything in github is linkable, btw)
jnthn :) 19:01
brrt ... having a sigil change for pointer-typed operands seems like a way to have less template bugs, and less template bugs is pretty high on the priority list. Only choice is 'which one'
jnthn Thanks for explaining; wrote a follow-up comment, should probably try swapping it back with the change to see
brrt aha, hmm
if changing to $res only didn't work, that looks like I have a register allocator bug on my hands 19:02
I will check it out
jnthn It was the end of the day and hot, so I mighta messed up :)
brrt :-)
available sigils: [~`%*_+'<>\/] 19:03
hell, we could even do {0}
or <, >, . 19:04
jnthn Too bad we don't have & :)
brrt (Or, even, \$0
& is taken for macro's
C macro's 19:05
jnthn \$0 is Perl-y
brrt hmmm
jnthn I guess * is pointer-y put the wrong way around perhaps :)
brrt I could be swayed for another sigil for C-macro's, but I kind of like \$0 now
19:14 lizmat left 19:25 domidumont left
dogbert17 jnthn: might possibly have found something useful, gist.github.com/dogbert17/a6ee6ddd...6eca767716 19:29
jnthn ooh, that's a good one 20:13
Let's see if I can get it to happen here 20:15
No joy reproducing it here 20:19
nwc10 jnthn: MoarVM on origin/postrelease-opts, + #define MVM_SPESH_CHECK_DU 1 + export MVM_SPESH_NODELAY=1 20:20
NQP build explodes. I think on gen/moar/stage1/NQPP6QRegex.moarvm
OK, no, not that. but it does explode with a lot of spesh backtrace 20:21
jnthn Ah, that's probably from the graph checker 20:22
20:22 brrt left
nwc10 of course, now I think I'm re-running with the same setup and it's working 20:23
jnthn You generally want MVM_SPESH_BLOCKING=1 in there too, or it's not going to be reproducible
nwc10 but something reliably went boom earlier, and I thought I'd pared it down to the minimum amount of non-default
aha
jnthn Though if you have the spesh backtrace to hand still, there's a decent chance I can figure out what happened from it 20:24
nwc10 can probably do that soon
paste.scsys.co.uk/581554 20:27
all 1545 lines
I hope 20:28
20:28 lizmat joined
dogbert17 jnthn: I can't say that it happens every time I'm afraid 20:28
nwc10 I need to go to bed (been up for too long) so can't re-run that tonight
20:29 p6bannerbot sets mode: +v lizmat
dogbert17 I can repro it once in approximately ten runs 20:31
Geth MoarVM/postrelease-opts: ce2b91771f | (Jonathan Worthington)++ | src/core/fixedsizealloc.c
Simplify realloc_at_safepoint debug code

No need to add on to a pointer only to subtract from it again.		 20:39
MoarVM/postrelease-opts: ec83f8cf5a | (Jonathan Worthington)++ | src/gc/collect.c
Add debugging range check on SC index
jnthn nwc10: thanks
dogbert17: I can't yet repro it in at least that many runs, but it's maybe worth seeing if it trips that new debug check I added
away for a bit :) 20:41
dogbert17 which check is that?
sry, will learn how to read
20:42 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke
dogbert17 ok 14 - Updated value seen by non-atomic too 20:43
MoarVM panic: SC index out of range
jnthn: the gist of the matter - gist.github.com/dogbert17/24e6033e...c8cfdfb444 20:53
jnthn dogbert17: Thanks. Unfortunately, that makes the ASAN output a little less helpful in figuring out any more 21:59
(It's just an overrun)
(But because the sc index is way too high)
Wow, it's entirely bogus 22:00
22:02 lizmat left
MasterDuke i think that's usually the case (that the sc index is so high as to be bogus) 22:03
jnthn Very odd 22:05
timotimo i don't think i've checked yet if it perhaps got negative for some odd reason 22:09
m: say 55807408.base(16) 22:10
camelia 3538DB0
timotimo not really, no
MasterDuke timotimo: is this the sort of thing rr would be good for? you could watch sc_index backward in time? 22:16
22:18 enonvf joined
timotimo sounds plausible 22:19
22:19 p6bannerbot sets mode: +v enonvf 22:23 enonvf left 22:29 lizmat joined 22:30 p6bannerbot sets mode: +v lizmat 22:36 njm joined, p6bannerbot sets mode: +v njm 23:08 lizmat left
jnthn Interesting. One of my work apps managed to trip the fromspace assert during spesh plugin evaluation 23:09
I placed some more and it turns out it's the value being fed in as an argument to the plugin that is bad 23:10
However, I can only get it to happen with the JIT
It's raining! \o/ 23:19
timotimo \o/
we had a bunch of water fall onto our surroundings, as well
jnthn Forecast for tomorrow is a more sensible temperature, and the weekend will be decidedly more pleasant :) 23:21
MasterDuke jnthn: how come the MVM_repr_alloc_init in the interp.c version of expmod_I doesn't need to be MVMROOTed? 23:22
compared to the other ops that do the MVM_repr_alloc_init in the function 23:23
jnthn What would be rooted?
type is the only local and it's not used after the allocation 23:24
MasterDuke ah
jnthn And GET_REG reads from the registers, which will be marked
So it's safe
MasterDuke fwiw, i'm working on a branch to convert it to allocating in the function (and make the _I ops a little more consistent overall) 23:25
jnthn consistency++ 23:30
There may be more ops that we can add sp_*_I variants of too
'night o/ 23:58

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!