github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 25 August 2013.
timotimo is this for a self-hosting nqp now? 00:03
TimToady yup
00:04 colomon joined
jnthn 'night 00:08
01:08 FROGGS_ joined
diakopter 8,212,029 C function calls when running 55-multi-method.t -_- 01:44
TimToady if we could just rid of all that C overhead, we might get somewhere... :) 02:06
diakopter *titter* 02:07
JimmyZ 512 REPR(obj)->gc_free(tc, obj); 02:15
1: *(((MVMObject *)(obj))->st)->REPR = {type_object_for = 0x60002800000000, allocate = 0, initialize = 0x11853f0, copy_to = 0x91fd88, attr_funcs = 0x0, box_funcs = 0x1305960, pos_funcs = 0xf34fe0, ass_funcs = 0xf36c90, elems = 0, get_storage_spec = 0, change_type = 0, serialize = 0, deserialize = 0x60002800000000, serialize_repr_data = 0, deserialize_repr_data = 0x11853f0, deserialize_stable_size = 0x91fd88, gc_mark = 0, gc_free = 0x13058e0
(gdb) n 02:16
Program received signal SIGSEGV, Segmentation fault.
diakopter: have an interest?
diakopter JimmyZ: no... it's what jnthn was working on for hours.. 02:17
JimmyZ ;)
02:23 colomon joined 02:24 foo_bar_baz joined
JimmyZ .tell jnthn if you get segfault with `../moarvm nqp.moarvm t/nqp/57-construction.t`, hope this will help you gist.github.com/zhuomingliang/6401...tfile1.txt 02:26
yoleaux JimmyZ: I'll pass your message to jnthn.
JimmyZ .tell jnthn and gist.github.com/zhuomingliang/6401...tfile1.txt 02:41
yoleaux JimmyZ: I'll pass your message to jnthn.
diakopter why do we have 277,912 calls to memcmp!?!?
and 378257 02:42
calls to memcpy
*headdesk*
there's gobs of LHF 02:44
wow... so.. much.. that could be improved 03:05
of course, still quite hard to know whether the C compiler already improves it.
JimmyZ .tell jnthn ignore 666e0d27126409f55489b98bb7fdd04942b28a05 one 03:14
yoleaux JimmyZ: I'll pass your message to jnthn.
dalek arVM: d560772 | diakopter++ | src/6model/reprs/MVMHash.c:
missing write barriers and more standard write barriers
 03:16
arVM: 6ef0ae3 | diakopter++ | src/6model/reprs/ (2 files):
more missing write barriers
 03:21
JimmyZ .tell jnthn I fixed the segfault by this patch: gist.github.com/zhuomingliang/6402151 03:29
yoleaux JimmyZ: I'll pass your message to jnthn.
diakopter JimmyZ: we need to know what object wants something bigger than that
JimmyZ diakopter: yes
diakopter did you find which one? 03:30
JimmyZ diakopter: not sure, but pre one object size is 64 03:31
diakopter 64 what...
JimmyZ diakopter: see gist.github.com/zhuomingliang/6401...tfile1.txt 03:32
diakopter ahhhhhhhhhhhhhhhhhhhhhhhhh my eyes!!!!!!!!!!!!!!!
if only I knew what was going on here.. 03:33
ok, I see 03:34
JimmyZ oh, the 64 was cast from uint32 to uint16 03:35
diakopter so... 03:36
what's wrong with that
oh.
wait, no, what's wrong with that? 03:37
JimmyZ I don't know what's wrong, by I can't find any one that size > 600 03:44
diakopter it must be from some object that's not allocated by MVM_gc_allocate* 03:45
JimmyZ well, the biggest size is 2000 04:08
err, 200
.tell jnthn but the largest item->size number I got is 200 04:17
yoleaux JimmyZ: I'll pass your message to jnthn.
JimmyZ .tell jnthn I got the weird thing. with MVMuint16 size, any item->size greater than 184 will be changed to 184 04:50
yoleaux ...
diakopter there's gotta be some basic C thing we're missing 05:10
bbl
07:03 cognominal joined, FROGGS[mobile] joined 07:30 foo_bar_baz joined
JimmyZ diakopter: or changes the flag to int32 works also 07:34
*uint32 07:35
nwc10 .tell jnthn if I run `../moarvm nqp.moarvm t/nqp/53-knowhow.t` it passes (reliably) but it fails reliably (Non-zero wait status: 11) if run by the harness. To me this is suspicion, but I have no idea what it's telling me. 07:44
yoleaux nwc10: I'll pass your message to jnthn.
nwc10 naughty fingers 07:45
with auto-correct getting it wrong
moritz moarvm configure fail on latest master: git error: fatal: reference is not a tree: a9e6eec70785f43f63ef17189fc2733d4ceb8446 07:51
Unable to checkout 'a9e6eec70785f43f63ef17189fc2733d4ceb8446' in submodule path '3rdparty/dyncall'
looks like somebody forgot to push a dyncall revision 07:52
nwc10 worked on my machine 07:54
moritz fwiw it seems that Makefile is still generated 08:01
JimmyZ moritz: git submodule sync 08:08
moritz JimmyZ: thanks 08:15
JimmyZ: should Configure.pl do that for me? 08:16
JimmyZ moritz: nope, just because someone changed the github dyncall repo from my github account to MoarVM one 08:17
moritz JimmyZ: ok
10:07 foo_nar_baz joined 10:25 eternaleye joined 11:14 colomon joined
diakopter
.oO( where be jnthn? )
 11:39
JimmyZ He is at A place where starts with 'S' 11:44
11:50 lizmat joined
jnthn diakopter: Taking care of some stuff for the upcoming week of teaching... :) 12:59
13:28 benabik joined
diakopter jnthn: whee :) 13:42
jnthn :)
It's all "easy" teaching material wise, but still probably quite tiring
arnsholt nwc10: Wait status 11 is segfault, isn't it? 14:00
So if it segfaults when run by the harness but not from the shell, there might be some shenanigans going on triggered by stack layout or somesuch 14:01
jnthn It's almost certainly a getting lucky/unlucky with layout thing 14:26
Also interesting is if you disable the sweep through to gc_free all the dead in the old nursery, we pass all but 2 of the tests, which fail for legit reasons rather than segfaults. 14:33
14:39 FROGGS joined
JimmyZ jnthn: or change 'if (!(item->flags & (MVM_CF_TYPE_OBJECT | MVM_CF_STABLE))) {' to if (item->flags && !(item->flags & (MVM_CF_TYPE_OBJECT | MVM_CF_STABLE))) {' in MVM_gc_collect_free_nursery_uncopied 14:46
we also pass all but 2
FROGGS JimmyZ: with that patch?
JimmyZ yes
FROGGS cool!
JimmyZ but it's a wrong patch 14:47
FROGGS meh :o(
JimmyZ: if I only change this line, all tests fail 14:48
jnthn Right, all it's doing is avoiding the issue, not fixing anything. 14:49
I'm a little further forward now.
JimmyZ shouldn't fail, it only aovids the gc free issue
FROGGS t/nqp/01-literals.t ................... Internal error: impossible case encountered in GC free
JimmyZ jnthn: Did you see my gist pathc?
jnthn It appears that the st pointer of the object in question is valid, but the ST's memory has been scribbled over...
JimmyZ jnthn: *patch
14:50 cognominal joined
jnthn JimmyZ: yes, but it's also seemingly just avoiding the problem not fixing it. 14:50
JimmyZ: That is, changes memory layout.
JimmyZ yes, I'm just curious why two int16 there cause the issue 14:52
jnthn I doubt it's the issue
It's a memory corruption problem 14:53
jnthn sees if he can catch it with a data breakpoint...
JimmyZ what needs to catch? 14:55
jnthn JimmyZ: When memory gets corrupted 14:56
And yes, it catches it... :)
Only deepens the mystery, tough...
*though 14:57
JimmyZ oh, how do you do it
jnthn Debug > New Breakpoint > New Data Breakpoint
Can get it to break whenever a certain memory address is modified. 14:58
Looking at it, I somewhat suspect that an object is being allocated whose ST pointer is in the old nursery... 15:00
JimmyZ well, it also works if I added 'MVMuint16 dummy;' after 'MVMuint16 flags', as long as 'MVMuint16 size' is not after 'MVMuint16 flags' 15:02
or not aligned with flags 15:03
jnthn None of the evidence I have here suggests it's anything to do with the size/flags 15:07
JimmyZ yes, I changed 'MVMuint16 size;' to 'MVMuint16 dummp; MVMuint8 size;', and it works also!
jnthn if ((char*)st >= tc->nursery_fromspace && (char*)st <= ((char*)tc->nursery_fromspace + MVM_NURSERY_SIZE))
MVM_exception_throw_adhoc(tc, "Alocating object with fromspace ST");
Shoving that in MVM_gc_allocate_object explodes. 15:08
That's the real problem.
Also, I get a backtrace telling me what it's allocating...
uh, where...
JimmyZ yes, the size works well in allocation.c, it just doesn't work in collect.c 15:12
:/
jnthn For the nth, time, it's not about size!!! 15:13
method mergesubrule($start, $to, $fate, $cursor, str $name, %caller_seen?) {
#nqp::say("adding $name");
my %seen := nqp::clone(%caller_seen);
The crash happens here; %caller_seen has not had its ST updated
JimmyZ oh 15:14
jnthn In fact, the object we're cloning also is in fromspace... 15:21
jnthn wonders if we're failing to walk through the args-passing area... 15:22
FROGGS maybe optionals are treated special/wrong?
jnthn No, it's that the GC happens while we're in the process of taking args from the arg buffer area and doing binding. That binding of parameters can cause boxing and thus allocation. 15:24
But the args buffer isn't yet being walked.
So, that's the problem. 15:25
FROGGS I think I understand
jnthn So, I know what needs fixing now. 15:29
Hopefully are the segfaults are due to this same thing. 15:30
diakopter jnthn: ooo oooo what needs fixing 15:40
I guess I should read the backlog 15:41
oh. args area.
heh.
jnthn "needed", it looks like :) 15:43
diakopter nice. 15:44
jnthn That took some debugging...
diakopter some++ debugging++
jnthn Of course, the patch it leads to is comparatively tiny 15:45
Coming in a moment. 15:46
yay, we're doing to three failures from t/nqp. Two backtraces, one (non-GC) segfault.
dalek arVM: 3dc4cff | jnthn++ | src/ (4 files):
The arg buffer must be walked during GC.

Failure to do so means that any parameter binding process that causes allocations could end up pulling things out of an args buffer full of old pointers.		 15:48
FROGGS jnthn++ # three failing test files left \\o/ 15:49
jnthn FROGGS: You get same?
t\\nqp\\56-role.t ....................... Bytecode validation error: missing final return instruction
FROGGS t/nqp/56-role.t ....................... Bytecode validation error: missing final return instruction 15:50
jnthn ...that's a curious one... :)
FROGGS seems so :o)
diakopter that's indicative of another problem
because compiler.c always adds a final return instruction
jnthn Right, I thought so too.
Who understands the bytecode validator? :D
diakopter I think there's a printf line in there somewhere you can uncomment 15:51
FROGGS hides
diakopter or maybe in the file commit history
see if the dumper barfs on it
timotimo i can't seem to check out the libuv submodule
git error: error: RPC failed; result=18, HTTP code = 200 - weird.
diakopter have masttocu also write it to a file or dump it
FROGGS Bytecode validation error: missing final return instruction 15:52
at nqp-src/nqp-mo.pm:569 (./nqp-mo.moarvm:specialize:29)
jnthn Well, I could implement masttofile and then make sure --target=mbc work
15:53 ggoebel joined
timotimo rm -rf * in the moarvm checkout and re-running configure seems to help 15:53
FROGGS there is something about `git submodule update` in the clogs 15:54
dalek arVM: 354226e | jnthn++ | src/6model/containers.c:
Fix container configuration storage.

Keep the key string around, so the hash won't point off into random memory.		 16:01
jnthn And then there were 2...
FROGGS jnthn: does this fix #56 ? 16:03
jnthn no
FROGGS k
jnthn Fixed 67-container.t
Which wsa the last segfaulting one.
The last 2 just backtrace
I'm gonna leave 56 and hope somebody else digs into it :) 16:04
May look at 73 later, no idea how hard/easy it is
diakopter jnthn++
FROGGS jnthn++ # :o) 16:05
diakopter jnthn: why's it ok to add that one as a permanent?
jnthn Also will write a MoarVM status update blog post soon...
diakopter: Container configurations live forever...
diakopter oh
jnthn diakopter: Though, this hash really should hang off instance... :S 16:06
Then we could mark it that way
diakopter needs a lock then
jnthn True :)
Needs one now also :P
diakopter oh
jnthn huh wtf
uv_mutex_lock(&tc->instance->mutex_container_registry);
The mutex lives on instance
But not the darn struct
diakopter heh.
jnthn dangles the LHF :) 16:07
diakopter dodges
diakopter knocks it to JimmyZ
jnthn bbl 16:09
diakopter bbl
.. 16:55
dalek arVM/nativecall: 33aa5bb | (Gerhard R)++ | src/6model/reprs/C (3 files):
Work on CArray and CStruct
 18:04
18:04 not_gerd joined
not_gerd o/ 18:04
re 56-role.t
for some reason, frame_cuuid_67 ends up with bytecode_size == 0 18:05
however, not if you do a --dump
diakopter hrm 18:10
not_gerd deserialize_frames() also never reads a zero bytecode size 18:11
jnthn mmm...so hot 18:27
jnthn is back from dinner
18:32 Ulti left
not_gerd gives up trying to debug 56-role.t 18:49
the offending frame apparently does not get read from disk, and I couldn't find out where it gets created
jnthn Almost certainly in a code path leading from masttocu 18:50
(so yes,not from disk)
oh... 18:51
Actually, I'm wrong, look at the bt
*looking 18:52
Hm
benabik Line numbers in the backtraces seem to be a little off. 18:56
1 bytecode validation error, 1 segfault, 1 VMArray doesn't do associative 19:01
FROGGS www.youtube.com/watch?v=TIUUVEojULE - Jonathan Worthington. MoarVM a metamodel focused runtime for NQP and Rakudo 19:21
not_gerd wild guess, but could a frame with 0 bytecode_size be due to the still commented part of create_code() in NQP.nqp? 19:24
TimToady agh, who change run() and shell() to return the process status? the whole *point* of changing from system() was to change the return code to a Boolean! 19:27
where success is True 19:28
and failure is supposed to come through $!
FROGGS TimToady: you are talking about rakudo? 19:29
TimToady I'm talking about the specs
along with rakudo
FROGGS ahh
TimToady you were supposed to be able to say run("command") or warn "command failed: $!" 19:30
FROGGS pmurias and me changed shell() in rakudo lately, but I didn't touch the spec fwiw
TimToady not write backwards logic like you do with p5's system
that was the only reason we renamed it to run() was to change the API
not_gerd
.oO( shouldn't that complaint go to #perl6 )
TimToady yeah, sorry
FROGGS we did not touch run()
TimToady I'm just surprised it got through without me noticing before...and I'm rather grrrr about it still... 19:31
so maybe I should wander off and cool down first :)
oh wait, maybe I misread... 19:33
FROGGS perlcabal.org/syn/S29.html#line_552
it boolifies to success
19:45 _ilbot joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
not_gerd .tell jnthn could a frame with 0 bytecode_size be due to the still commented part of create_code() in NQP.nqp:228? 19:54
yoleaux not_gerd: I'll pass your message to jnthn.
not_gerd bye, #moarvm 19:55
19:55 not_gerd left
jnthn .tell not_gerd that needs doing, but I think it's can't be that; the call to compunit_coderefs will die before we ever get there 'cus the op it depends on is also NYI 20:10
yoleaux 19:54Z <not_gerd> jnthn: could a frame with 0 bytecode_size be due to the still commented part of create_code() in NQP.nqp:228?
jnthn: I'll pass your message to not_gerd.
FROGGS gnight 20:13
dalek arVM: 053f6fa | jnthn++ | src/6model/reprs/P6opaque.c:
Positional/associative delegate v P6opaque.compose

The usage in QASTNode worked as it came from object serialized in the cross-compile. Needed handling of these in compose for it to work in selfhost, though. Fixes 73-delegation.t.		 21:22
jnthn There's one moar fixed :)
lizmat jnthn++
jnthn Only 56-role.t failing here now. 21:23
dalek arVM: 9edcbe4 | jnthn++ | src/6model/reprs/MVMStaticFrame.c:
Don't forget to copy bytecode_size.

Need to further review what MVMStaticFrame.copy_to is doing, but this gets 56-role.t a little further.		 21:31
jnthn The rest of the way needs more work that I have energy to do tonight.
diakopter like what? 21:54
dalek arVM: e065de9 | diakopter++ | nqp-cc/t/nqp/ (7 files):
the rest of the nqp test (7 of them).. we pass a few of them already
 22:12
jnthn diakopter: Run it, you'll see there's a missing op (cucoderefs or so) 22:40
diakopter: But after that there's another op needed too, I think... 22:41
diakopter: There's some code commented out in NQP.nqp
diakopter: Can probably steal inspiration from JVM port :)
'night o/
diakopter o/ 22:42
heh... moar now passes more of the nqp tests than the cross compiler to moar 22:43
(granted, the cross compiler is an nqp that's a bit more bitrotten) 22:44
tadzik any objections to changing make nqptest to run the nqp.moarvm rather than the cross-compiler? 22:45
oh, there's "selftest"
[Coke] eagerly awaits a bare minimum rakudo on moarvm so he can test it daily! 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!