dalek arVM/missing_mvmroot: 97d288c | (Jimmy Zhuo)++ | src/core/args.c:
fixed arg_flags allocation
07:02
brrt JimmyZ: I'll take a look at it if you want 07:21
JimmyZ: a MVMCallSiteentry is typedef'd as MVMuint8 07:25
your patch is not wrong, but neither was the original code
dalek arVM/missing_mvmroot: b05affd | (Jimmy Zhuo)++ | src/ (2 files):
fix more missing MVMROOT
JimmyZ brrt: see github.com/MoarVM/MoarVM/blob/21ab...me.c#L1710 07:27
brrt also, know what *is* wrong (or at least overly evil):
github.com/MoarVM/MoarVM/blob/97d2...rgs.c#L730 07:28
realloc with inline multiplication
and yes, I've been there and done it myself
I know JimmyZ, but itis also redundant there :-) 07:29
meh, not your fault, i would've made the same change :-)
JimmyZ brrt: I cares about it because github.com/MoarVM/MoarVM/issues/412 07:30
brrt: which segfaults in arg_flags
brrt: though I don't know how to fix it yet 07:31
:P
brrt let's see 07:53
on the other hand, adding it is better than not, because we might decide to change the size of MVMCallsiteEntry at some poing
brrt hmmm... i find that i'm not very much enthusiastic to fix the 'old' register allocator to work with the new tile structure... 08:35
but, better to do it so that the change is minimal 08:36
dalek arVM/missing_mvmroot: ac12696 | (Jimmy Zhuo)++ | src/core/ (3 files):
fixed more arg_flags allocation
09:04
dogbert17 hmm, no spectest fails with 128k nursery and lots of debug flags, damn looks like I'm out of a job :-) 13:40
jnthn Time for 64k! ;) 13:41
There's also still an issue with a 10KB or smaller nursery in socket-recv-vs-read.t or whatever it's called 13:42
dogbert17 ok then, 64k it is 13:44
brrt it ought to be enough for anyone 13:50
jnthn dogbert17: Oh, if you're looking for bug hunting to do: the docs build was also crashing over fromspace access when I accidentally left some of the debugging checks enabled in the normal build 13:52
They are no longer, and it only failed sometimes, and it may be that one of yesterday's fixes nailed it
But could be worth trying it out to see if it tickles anything 13:53
dogbert17 jnthn: will look at that as well 14:02
nine (bug hunters)++ 14:03
dogbert17 running make spectest with a small nursery is sloooow 15:47
jnthn Ain't it just...especially with all the extra sanity checks on :) 15:54
dogbert17 I'm at S03-* now, only one fail so fair t/spec/S03-metaops/hyper.rakudo.moar 15:55
dogbert17 jnthn: does the following gist contain anything that might be useful? gist.github.com/dogbert17/44f312ac...c7757110c5 17:20
jnthn dogbert17: Somewhat, yes :) 17:21
dogbert17 when I increased the nursery to 128k everything worked 17:22
should I report it or is there a way to get more information? 17:25
jnthn Well, it's a tad tricky from here 17:26
The next step I'd take is to grab a dump of the bytecode 17:27
And then try and figure out where in it we are
The interp.c line number (not check_reg, the frame below) points to the instruction we were executing at the time
You might also try with an even smaller nursery to try and get a different/more informative trigger
dogbert17 jnthn: you mean this MVM_interp_run (tc=0x804c450, initial_invoke=0xb7dc902a <toplevel_initial_invoke>, invoke_data=0x80a3cc8) at src/core/interp.c:5260 17:28
dogbert17 I ran it in gdb again so some numbers might have changed 17:29
5259 OP(sp_getarg_s): 17:31
5260 GET_REG(cur_op, 0).s = tc->cur_frame->params.args[GET_UI16(cur_op, 2)].s;
5261 cur_op += 4;
5262 goto NEXT;
jnthn Hm, interesting indeed 17:38
That'll need further digging :)
Since somehow the args buffer is outdated 17:39
I'm away for a bit for dinner and stuff; feel free to file it with this info :)
dogbert17 done, issue 456 17:54