Camelia, the Perl 6 bug

IRC log for #moarvm, 2013-09-01

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:03 timotimo is this for a self-hosting nqp now?
00:03 TimToady yup
00:04 colomon joined #moarvm
00:08 jnthn 'night
01:08 FROGGS_ joined #moarvm
01:44 diakopter 8,212,029 C function calls when running 55-multi-method.t  -_-
02:06 TimToady if we could just rid of all that C overhead, we might get somewhere... :)
02:07 diakopter *titter*
02:15 JimmyZ 512                     REPR(obj)->gc_free(tc, obj);
02:15 JimmyZ 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
02:16 JimmyZ (gdb) n
02:16 JimmyZ Program received signal SIGSEGV, Segmentation fault.
02:16 JimmyZ diakopter: have an interest?
02:17 diakopter JimmyZ: no... it's what jnthn was working on for hours..
02:17 JimmyZ ;)
02:23 colomon joined #moarvm
02:24 foo_bar_baz joined #moarvm
02:26 JimmyZ .tell jnthn if you get segfault with `../moarvm nqp.moarvm t/nqp/57-construction.t`, hope this will help you https://gist.github.com/zhuominglia​ng/6401892/raw/666e0d27126409f55489​b98bb7fdd04942b28a05/gistfile1.txt
02:26 yoleaux JimmyZ: I'll pass your message to jnthn.
02:41 JimmyZ .tell jnthn and https://gist.github.com/zhuominglia​ng/6401892/raw/1b70efe5077064eed265​f66c57633e39cae27863/gistfile1.txt
02:41 yoleaux JimmyZ: I'll pass your message to jnthn.
02:41 diakopter why do we have 277,912 calls to memcmp!?!?
02:42 diakopter and 378257
02:42 diakopter calls to memcpy
02:42 diakopter *headdesk*
02:44 diakopter there's gobs of LHF
03:05 diakopter wow... so.. much.. that could be improved
03:05 diakopter of course, still quite hard to know whether the C compiler already improves it.
03:14 JimmyZ .tell jnthn ignore 666e0d27126409f55489b98bb7fdd04942b28a05 one
03:14 yoleaux JimmyZ: I'll pass your message to jnthn.
03:16 dalek MoarVM: d560772 | diakopter++ | src/6model/reprs/MVMHash.c:
03:16 dalek MoarVM: missing write barriers and more standard write barriers
03:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d5607728b6
03:21 dalek MoarVM: 6ef0ae3 | diakopter++ | src/6model/reprs/ (2 files):
03:21 dalek MoarVM: more missing write barriers
03:21 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6ef0ae3186
03:29 JimmyZ .tell jnthn I fixed the segfault by this patch: https://gist.github.com/zhuomingliang/6402151
03:29 yoleaux JimmyZ: I'll pass your message to jnthn.
03:29 diakopter JimmyZ: we need to know what object wants something bigger than that
03:29 JimmyZ diakopter: yes
03:30 diakopter did you find which one?
03:31 JimmyZ diakopter: not sure, but pre one object size is 64
03:31 diakopter 64 what...
03:32 JimmyZ diakopter: see https://gist.github.com/zhuominglia​ng/6401892/raw/1b70efe5077064eed265​f66c57633e39cae27863/gistfile1.txt
03:32 diakopter ahhhhhhhhhhhhhhhhhhhhhhhhh my eyes!!!!!!!!!!!!!!!
03:33 diakopter if only I knew what was going on here..
03:34 diakopter ok, I see
03:35 JimmyZ oh, the 64 was cast from uint32 to uint16
03:36 diakopter so...
03:36 diakopter what's wrong with that
03:36 diakopter oh.
03:37 diakopter wait, no, what's wrong with that?
03:44 JimmyZ I don't know what's wrong, by I can't find any one that size > 600
03:45 diakopter it must be from some object that's not allocated by MVM_gc_allocate*
04:08 JimmyZ well, the biggest size is 2000
04:08 JimmyZ err, 200
04:17 JimmyZ .tell jnthn but the largest item->size number I got is 200
04:17 yoleaux JimmyZ: I'll pass your message to jnthn.
04:50 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 ...
05:10 diakopter there's gotta be some basic C thing we're missing
05:10 diakopter bbl
07:03 cognominal joined #moarvm
07:03 FROGGS[mobile] joined #moarvm
07:30 foo_bar_baz joined #moarvm
07:34 JimmyZ diakopter: or changes the flag to int32 works also
07:35 JimmyZ *uint32
07:44 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.
07:45 nwc10 naughty fingers
07:45 nwc10 with auto-correct getting it wrong
07:51 moritz moarvm configure fail on latest master:  git error: fatal: reference is not a tree: a9e6eec70785f43f63ef17189fc2733d4ceb8446
07:51 moritz Unable to checkout 'a9e6eec70785f43f63ef17189fc2733d4ceb8446' in submodule path '3rdparty/dyncall'
07:52 moritz looks like somebody forgot to push a dyncall revision
07:54 nwc10 worked on my machine
08:01 moritz fwiw it seems that Makefile is still generated
08:08 JimmyZ moritz: git submodule sync
08:15 moritz JimmyZ: thanks
08:16 moritz JimmyZ: should Configure.pl do that for me?
08:17 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 #moarvm
10:25 eternaleye joined #moarvm
11:14 colomon joined #moarvm
11:39 diakopter .oO( where be jnthn? )
11:44 JimmyZ He is at A place where starts with 'S'
11:50 lizmat joined #moarvm
12:59 jnthn diakopter: Taking care of some stuff for the upcoming week of teaching... :)
13:28 benabik joined #moarvm
13:42 diakopter jnthn: whee :)
13:42 jnthn :)
13:42 jnthn It's all "easy" teaching material wise, but still probably quite tiring
14:00 arnsholt nwc10: Wait status 11 is segfault, isn't it?
14:01 arnsholt 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:26 jnthn It's almost certainly a getting lucky/unlucky with layout thing
14:33 jnthn 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:39 FROGGS joined #moarvm
14:46 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 JimmyZ we also pass all but 2
14:46 FROGGS JimmyZ: with that patch?
14:46 JimmyZ yes
14:46 FROGGS cool!
14:47 JimmyZ but it's a wrong patch
14:47 FROGGS meh :o(
14:48 FROGGS JimmyZ: if I only change this line, all tests fail
14:49 jnthn Right, all it's doing is avoiding the issue, not fixing anything.
14:49 jnthn I'm a little further forward now.
14:49 JimmyZ shouldn't fail, it only aovids the gc free issue
14:49 FROGGS t/nqp/01-literals.t ................... Internal error: impossible case encountered in GC free
14:49 JimmyZ jnthn: Did you see my gist pathc?
14:49 jnthn It appears that the st pointer of the object in question is valid, but the ST's memory has been scribbled over...
14:49 JimmyZ jnthn: *patch
14:50 cognominal joined #moarvm
14:50 jnthn JimmyZ: yes, but it's also seemingly just avoiding the problem not fixing it.
14:50 jnthn JimmyZ: That is, changes memory layout.
14:52 JimmyZ yes, I'm just curious why two int16 there cause the issue
14:52 jnthn I doubt it's the issue
14:53 jnthn It's a memory corruption problem
14:53 * jnthn sees if he can catch it with a data breakpoint...
14:55 JimmyZ what needs to catch?
14:56 jnthn JimmyZ: When memory gets corrupted
14:56 jnthn And yes, it catches it... :)
14:56 jnthn Only deepens the mystery, tough...
14:57 jnthn *though
14:57 JimmyZ oh, how do you do it
14:57 jnthn Debug > New Breakpoint > New Data Breakpoint
14:58 jnthn Can get it to break whenever a certain memory address is modified.
15:00 jnthn Looking at it, I somewhat suspect that an object is being allocated whose ST pointer is in the old nursery...
15:02 JimmyZ well, it also works if I added 'MVMuint16 dummy;' after 'MVMuint16 flags', as long as 'MVMuint16 size' is not after 'MVMuint16 flags'
15:03 JimmyZ or not aligned with flags
15:07 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!
15:07 jnthn if ((char*)st >= tc->nursery_fromspace && (char*)st <= ((char*)tc->nursery_fromspace + MVM_NURSERY_SIZE))
15:07 jnthn MVM_exception_throw_adhoc(tc, "Alocating object with fromspace ST");
15:08 jnthn Shoving that in MVM_gc_allocate_object explodes.
15:08 jnthn That's the real problem.
15:08 jnthn Also, I get a backtrace telling me what it's allocating...
15:08 jnthn uh, where...
15:12 JimmyZ yes, the size works well in allocation.c, it just doesn't work in collect.c
15:12 JimmyZ :/
15:13 jnthn For the nth, time, it's not about size!!!
15:13 jnthn method mergesubrule($start, $to, $fate, $cursor, str $name, %caller_seen?) {
15:13 jnthn #nqp::say("adding $name");
15:13 jnthn my %seen := nqp::clone(%caller_seen);
15:13 jnthn The crash happens here; %caller_seen has not had its ST updated
15:14 JimmyZ oh
15:21 jnthn In fact, the object we're cloning also is in fromspace...
15:22 * jnthn wonders if we're failing to walk through the args-passing area...
15:22 FROGGS maybe optionals are treated special/wrong?
15:24 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 jnthn But the args buffer isn't yet being walked.
15:25 jnthn So, that's the problem.
15:25 FROGGS I think I understand
15:29 jnthn So, I know what needs fixing now.
15:30 jnthn Hopefully are the segfaults are due to this same thing.
15:40 diakopter jnthn: ooo oooo what needs fixing
15:41 diakopter I guess I should read the backlog
15:41 diakopter oh. args area.
15:41 diakopter heh.
15:43 jnthn "needed", it looks like :)
15:44 diakopter nice.
15:44 jnthn That took some debugging...
15:44 diakopter some++ debugging++
15:45 jnthn Of course, the patch it leads to is comparatively tiny
15:46 jnthn Coming in a moment.
15:46 jnthn yay, we're doing to three failures from t/nqp. Two backtraces, one (non-GC) segfault.
15:48 dalek MoarVM: 3dc4cff | jnthn++ | src/ (4 files):
15:48 dalek MoarVM: The arg buffer must be walked during GC.
15:48 dalek MoarVM:
15:48 dalek MoarVM: Failure to do so means that any parameter binding process that causes
15:48 dalek MoarVM: allocations could end up pulling things out of an args buffer full of
15:48 dalek MoarVM: old pointers.
15:48 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3dc4cffa62
15:49 FROGGS jnthn++ # three failing test files left \o/
15:49 jnthn FROGGS: You get same?
15:49 jnthn t\nqp\56-role.t ....................... Bytecode validation error: missing final return instruction
15:50 FROGGS t/nqp/56-role.t ....................... Bytecode validation error: missing final return instruction
15:50 jnthn ...that's a curious one... :)
15:50 FROGGS seems so :o)
15:50 diakopter that's indicative of another problem
15:50 diakopter because compiler.c always adds a final return instruction
15:50 jnthn Right, I thought so too.
15:50 jnthn Who understands the bytecode validator? :D
15:51 diakopter I think there's a printf line in there somewhere you can uncomment
15:51 * FROGGS hides
15:51 diakopter or maybe in the file commit history
15:51 diakopter see if the dumper barfs on it
15:51 timotimo i can't seem to check out the libuv submodule
15:51 timotimo git error: error: RPC failed; result=18, HTTP code = 200 - weird.
15:51 diakopter have masttocu also write it to a file or dump it
15:52 FROGGS Bytecode validation error: missing final return instruction
15:52 FROGGS at nqp-src/nqp-mo.pm:569  (./nqp-mo.moarvm:specialize:29)
15:52 jnthn Well, I could implement masttofile and then make sure --target=mbc work
15:53 ggoebel joined #moarvm
15:53 timotimo rm -rf * in the moarvm checkout and re-running configure seems to help
15:54 FROGGS there is something about `git submodule update` in the clogs
16:01 dalek MoarVM: 354226e | jnthn++ | src/6model/containers.c:
16:02 dalek MoarVM: Fix container configuration storage.
16:02 dalek MoarVM:
16:02 dalek MoarVM: Keep the key string around, so the hash won't point off into random
16:02 dalek MoarVM: memory.
16:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/354226e6fd
16:02 jnthn And then there were 2...
16:03 FROGGS jnthn: does this fix #56 ?
16:03 jnthn no
16:03 FROGGS k
16:03 jnthn Fixed 67-container.t
16:03 jnthn Which wsa the last segfaulting one.
16:03 jnthn The last 2 just backtrace
16:04 jnthn I'm gonna leave 56 and hope somebody else digs into it :)
16:04 jnthn May look at 73 later, no idea how hard/easy it is
16:04 diakopter jnthn++
16:05 FROGGS jnthn++ # :o)
16:05 diakopter jnthn: why's it ok to add that one as a permanent?
16:05 jnthn Also will write a MoarVM status update blog post soon...
16:05 jnthn diakopter: Container configurations live forever...
16:05 diakopter oh
16:06 jnthn diakopter: Though, this hash really should hang off instance... :S
16:06 jnthn Then we could mark it that way
16:06 diakopter needs a lock then
16:06 jnthn True :)
16:06 jnthn Needs one now also :P
16:06 diakopter oh
16:06 jnthn huh wtf
16:06 jnthn uv_mutex_lock(&tc->instance-​>mutex_container_registry);
16:06 jnthn The mutex lives on instance
16:06 jnthn But not the darn struct
16:06 diakopter heh.
16:07 * jnthn dangles the LHF :)
16:07 * diakopter dodges
16:07 * diakopter knocks it to JimmyZ
16:09 jnthn bbl
16:09 diakopter bbl
16:55 diakopter ..
18:04 dalek MoarVM/nativecall: 33aa5bb | (Gerhard R)++ | src/6model/reprs/C (3 files):
18:04 dalek MoarVM/nativecall: Work on CArray and CStruct
18:04 dalek MoarVM/nativecall: review: https://github.com/MoarVM/MoarVM/commit/33aa5bb8ae
18:04 not_gerd joined #moarvm
18:04 not_gerd o/
18:04 not_gerd re 56-role.t
18:05 not_gerd for some reason, frame_cuuid_67 ends up with bytecode_size == 0
18:05 not_gerd however, not if you do a --dump
18:10 diakopter hrm
18:11 not_gerd deserialize_frames() also never reads a zero bytecode size
18:27 jnthn mmm...so hot
18:27 * jnthn is back from dinner
18:32 Ulti left #moarvm
18:49 * not_gerd gives up trying to debug 56-role.t
18:49 not_gerd the offending frame apparently does not get read from disk, and I couldn't find out where it gets created
18:50 jnthn Almost certainly in a code path leading from masttocu
18:50 jnthn (so yes,not from disk)
18:51 jnthn oh...
18:51 jnthn Actually, I'm wrong, look at the bt
18:52 jnthn *looking
18:52 jnthn Hm
18:56 benabik Line numbers in the backtraces seem to be a little off.
19:01 benabik 1 bytecode validation error, 1 segfault, 1 VMArray doesn't do associative
19:21 FROGGS http://www.youtube.com/watch?v=TIUUVEojULE - Jonathan Worthington. MoarVM a metamodel focused runtime for NQP and Rakudo
19:24 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:27 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:28 TimToady where success is True
19:28 TimToady and failure is supposed to come through $!
19:29 FROGGS TimToady: you are talking about rakudo?
19:29 TimToady I'm talking about the specs
19:29 TimToady along with rakudo
19:29 FROGGS ahh
19:30 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
19:30 TimToady not write backwards logic like you do with p5's system
19:30 TimToady that was the only reason we renamed it to run() was to change the API
19:30 not_gerd .oO( shouldn't that complaint go to #perl6 )
19:30 TimToady yeah, sorry
19:30 FROGGS we did not touch run()
19:31 TimToady I'm just surprised it got through without me noticing before...and I'm rather grrrr about it still...
19:31 TimToady so maybe I should wander off and cool down first :)
19:33 TimToady oh wait, maybe I misread...
19:33 FROGGS http://perlcabal.org/syn/S29.html#line_552
19:33 FROGGS it boolifies to success
19:45 _ilbot joined #moarvm
19:45 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
19:54 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.
19:55 not_gerd bye, #moarvm
19:55 not_gerd left #moarvm
20:10 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?
20:10 yoleaux jnthn: I'll pass your message to not_gerd.
20:13 FROGGS gnight
21:22 dalek MoarVM: 053f6fa | jnthn++ | src/6model/reprs/P6opaque.c:
21:22 dalek MoarVM: Positional/associative delegate v P6opaque.compose
21:22 dalek MoarVM:
21:22 dalek MoarVM: The usage in QASTNode worked as it came from object serialized in the
21:22 dalek MoarVM: cross-compile. Needed handling of these in compose for it to work in
21:22 dalek MoarVM: selfhost, though. Fixes 73-delegation.t.
21:22 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/053f6faee6
21:22 jnthn There's one moar fixed :)
21:22 lizmat jnthn++
21:23 jnthn Only 56-role.t failing here now.
21:31 dalek MoarVM: 9edcbe4 | jnthn++ | src/6model/reprs/MVMStaticFrame.c:
21:31 dalek MoarVM: Don't forget to copy bytecode_size.
21:31 dalek MoarVM:
21:31 dalek MoarVM: Need to further review what MVMStaticFrame.copy_to is doing, but this
21:31 dalek MoarVM: gets 56-role.t a little further.
21:31 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9edcbe4394
21:31 jnthn The rest of the way needs more work that I have energy to do tonight.
21:54 diakopter like what?
22:12 dalek MoarVM: e065de9 | diakopter++ | nqp-cc/t/nqp/ (7 files):
22:12 dalek MoarVM: the rest of the nqp test (7 of them).. we pass a few of them already
22:12 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e065de9c57
22:40 jnthn diakopter: Run it, you'll see there's a missing op (cucoderefs or so)
22:41 jnthn diakopter: But after that there's another op needed too, I think...
22:41 jnthn diakopter: There's some code commented out in NQP.nqp
22:41 jnthn diakopter: Can probably steal inspiration from JVM port :)
22:41 jnthn 'night o/
22:42 diakopter o/
22:43 diakopter heh... moar now passes more of the nqp tests than the cross compiler to moar
22:44 diakopter (granted, the cross compiler is an nqp that's a bit more bitrotten)
22:45 tadzik any objections to changing make nqptest to run the nqp.moarvm rather than the cross-compiler?
22:45 tadzik oh, there's "selftest"
23:59 * [Coke] eagerly awaits a bare minimum rakudo on moarvm so he can test it daily!

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary