Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-21

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

All times shown according to UTC.

Time Nick Message
01:18 FROGGS__ joined #moarvm
05:24 woolfy joined #moarvm
05:28 lizmat joined #moarvm
06:07 woolfy left #moarvm
06:29 sergot morning o/
07:14 zakharyas joined #moarvm
08:22 odc joined #moarvm
08:37 brrt joined #moarvm
08:44 brrt \o
08:44 FROGGS__ hi brrt
08:44 brrt FROGGS_: the basic approach is to take the spesh log, see the difference between the original and the spesh'ed version, and follow up on peculiarities :-)
08:45 brrt hi :-)
08:46 FROGGS__ ahh, yeah....
08:47 FROGGS__ so I need the spesh log of the script that fails or the log when I compile the setting?
08:51 brrt does the setting fail? or the spectest?
08:51 brrt i think you'll need the one of the spectest
08:51 brrt because the one of the setting  is mostly compiler stuff
08:52 dalek MoarVM: 7694ea9 | (Tobias Leich)++ | tools/ucd2c.pl:
08:52 dalek MoarVM: follow latest string refactor in source-gen script
08:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7694ea914a
08:53 FROGGS__ brrt: the spectest
08:53 brrt ok, you'll need that one, then
08:53 FROGGS__ okay, yeah, I was think that spesh happens when running things... otherwise it can't guess what is hot I think
08:54 brrt exactly
08:59 brrt valgrind complains about heap corruption
08:59 brrt hmm
08:59 brrt and silly args to malloc
09:00 brrt that's not quite correct though; moarvm complains about heap corruption
09:00 brrt (this could, of course, well be another bug than the failing setting bug, happening not during rakudo but during nqp compilation)
09:02 brrt bbi2h
10:12 brrt joined #moarvm
10:13 * brrt back, but not directly at keyboard; anyone giving any advice - no matter how unfounded - is very, very welcome
10:13 brrt it seems doing the JIT directly causes 'silly mallocs'
10:13 brrt and i suspect that has something to do with the segv / heap corruption bug i'm seeing since i enabled some string ops
11:44 dalek MoarVM: 339d547 | (Tobias Leich)++ | / (2 files):
11:44 dalek MoarVM: add char name lookup aliases (LF,FF,CR and NEL)
11:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/339d547cdd
12:07 timotimo brother: we have 3 weeks to find this bug, then it's the suggested "pencils down" date
12:08 colomon joined #moarvm
12:11 FROGGS__ brrt you mean :o)
12:14 timotimo yes, sorry
12:15 FROGGS__ no brroblem
12:18 [Coke] He brought this on himself?
12:20 jnap joined #moarvm
12:29 klaas-janstol joined #moarvm
13:16 colomon joined #moarvm
13:45 jnap joined #moarvm
13:52 FROGGS[mobile] joined #moarvm
14:02 jimmyz joined #moarvm
14:04 brrt joined #moarvm
14:05 brrt timotimo: i'm already panicking!
14:41 carlin joined #moarvm
14:50 jnap joined #moarvm
14:54 timotimo i'm just a bit sad we've run into such a drastic bug ;(
14:57 dalek MoarVM: 503f76a | (Tobias Leich)++ | src/strings/ops.c:
14:57 dalek MoarVM: RT #122341 handle all line separators
14:57 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/503f76ac8b
14:57 synopsebot Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=122341
15:04 carlin Stage parse : moar in realloc(): error: bogus pointer (double free?) 0x198cad537dc0
15:04 carlin OpenBSD 5.5 amd64
15:04 carlin backtrace https://gist.github.com/carbin/ebb5c4eb0aedfaf5839c
15:04 carlin it was working fine last week
15:09 nwc10 this is current revisions of MoarVM, nqp and master?
15:09 nwc10 ASAN on gcc doesn't spot this
15:11 carlin HEAD rakudo, and whatever versions of nqp and Moar it's pulling in
15:13 nwc10 $ cat tools/build/NQP_REVISION
15:13 nwc10 2014.04-59-gb85f70e
15:13 nwc10 that's "Ancient", I think.
15:13 nwc10 I think that that's the problem (needs to be newer) but I'm not in an easy position to test that
15:13 nwc10 and I'm certainly not in a position to fix it
15:16 FROGGS__ 2014.04 is not realistic
15:17 FROGGS__ NQP_REVISION is 2014.07-11-gf1b098f right now
15:18 FROGGS__ and all components were at 2014.07 as of last Thursday
15:25 nwc10 oop, that was a stale checkout of mine
15:25 nwc10 I told you I'm doing too much :-/
15:25 FROGGS__ *g*
15:25 carlin NQP 2014.07-10-g908d8a0, MoarVM version 2014.07-7-g339d547
15:26 FROGGS__ and again the question raises if that is a speshbug or not...
15:26 FROGGS__ can you run it again under MVM_SPESH_DISABLE=1 ?
15:28 carlin with MVM_SPESH_DISABLE... Stage parse      : Segmentation fault (core dumped)
15:28 jnap joined #moarvm
15:29 FROGGS__ carlin: can you provide a backtrace for that one too?
15:37 carlin https://gist.github.com/carbin/0cec0bbd355227892e8f
15:46 brrt joined #moarvm
15:46 brrt well, so am i
15:51 brrt ok, what causes a pointer to past fromspace?
15:53 FROGGS__ I'm not sure if jnthn explained that in the infoq video, but it is possible
15:53 brrt ok, wrt to the backtrace, i find it very suspicious that both cur_op and bytecode_start are out of bounds
15:53 brrt it sure is :-) but it's wrong
15:54 FROGGS__ carlin: I think it is unlikely that it flips a 686002 bytes long string in the setting...
15:55 brrt good point FROGGS_ :-)
15:57 FROGGS__ okay, perhaps it really does that... for example there there is an <?after...> in a regex/grammar
15:57 brrt ...... wait a minute
15:59 brrt .... atkey_o and atpos_o are wrong, i'm sorry
15:59 FROGGS__ why are you sorry?
15:59 brrt both should store NULL if the invocant is NULL, which they don't (because a C call can't represent it)
15:59 brrt or... wait
16:00 brrt because i've spent so much time on this
16:00 brrt and never found it
16:00 brrt maybe the wrappers do this
16:01 FROGGS__ ahh, now I remember that I wanted to look at the spesh log for my other bug...
16:01 brrt wrappers don't do this
16:02 brrt and that explains /so much/
16:02 brrt (or it might)
16:03 FROGGS__ :o)
16:03 FROGGS__ I'm going to stay sceptical
16:04 brrt as rightly you should
16:04 brrt well, it doesn't fix the SEGV
16:05 brrt or the heap corruption
16:05 brrt so that's another thing
16:05 brrt but it just might fix the rakudo build bug
16:07 brrt well, it appears that it does
16:07 * brrt now feels a bit dumb
16:10 dalek MoarVM/moar-jit: 02bda67 | (Bart Wiegmans)++ | / (5 files):
16:10 dalek MoarVM/moar-jit: Add null_s, working on test for repeat_s
16:10 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/02bda6725e
16:10 dalek MoarVM/moar-jit: 0871366 | (Bart Wiegmans)++ | src/ (2 files):
16:10 dalek MoarVM/moar-jit: Fix bug in reprconv.c that stopped rakudo from building
16:10 dalek MoarVM/moar-jit:
16:10 dalek MoarVM/moar-jit: Also temporarily disabled isnull_s, which probably isn't wrong,
16:10 dalek MoarVM/moar-jit: but that does eventually enable a heap corruption somewhere.
16:10 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/08713667cb
16:11 brrt but, this version is compatible with building nqp/rakudo again
16:11 brrt such yay
16:12 nwc10 brrt: ish. Found /home/nicholas/Sandpit/moar-san/bin/moar version 2014.07-7-g339d547, which is too old.
16:12 brrt reconfigure and build :-)
16:12 brrt can't help that
16:13 nwc10 I *am* building from clean
16:13 nwc10 you sort of can if you're comfortable to merge master into jit, I think
16:13 nwc10 heck, I can try that locallyu
16:14 * brrt will see to that
16:15 nwc10 odd.
16:15 nwc10 /home/nicholas/Sandpit/moar-san/bin/moar
16:15 nwc10 is not getting updated
16:15 FROGGS__ brrt: when I do not --enable-jit, will it break anything?
16:15 brrt it should not
16:15 brrt but i don't test that as much as i should
16:15 nwc10 brrt: PEBKAC
16:15 FROGGS__ I'll test that later, and when nothing brakes, I would proposed we merge moar-jit into master
16:16 brrt no! there is still a heap corruption bug lingering
16:16 FROGGS__ bbiab, dinner &
16:16 FROGGS__ k
16:16 brrt when that's done, and when i've cleaned stuff up, then yes
16:16 brrt as soon as possible
16:16 brrt but no earlier
16:16 brrt :-)
16:16 brrt see you, thanks anyway :-)
16:17 brrt (np nwc10 :-) /me appreciates the help from all of you very much)
16:17 jnap joined #moarvm
16:21 brrt all of this is a testament, btw, of how few some code paths are really triggered
16:24 brrt and how diffiicult it can be to see how some stuff interacts
16:26 nwc10 brrt: upshot is that some of my previous "it's all fine" reports may be bogus
16:27 brrt how so?
16:27 nwc10 because I don't think I was building nqp and rakudo with the JIT-enabled MoarVM
16:30 brrt fair point
16:30 brrt well... if you do find anything, be sure to let me know :-)
16:34 btyler joined #moarvm
16:42 brrt btw, a little bit of weirdness - i find a mention of bailing on argconst_s
16:42 brrt but if that happened, then that means the argconst_s came /before/ prepargs
16:43 brrt let's investigate
16:43 brrt and that seems exactly what's happening
16:46 brrt ok, i should really prefix the jit log with the name and cuuid of the frame
16:46 brrt let's do that first
16:52 woolfy joined #moarvm
17:36 klaas-janstol joined #moarvm
17:49 FROGGS ummm, my spesh log diff is 29MB in size :/
17:54 FROGGS and it is totally useless
17:54 rurban probably no totally. I dump similar sized log files
17:55 brrt hmmm
17:55 brrt it helps if you can identify the frame at hand in the spesh log
17:55 timotimo sorry, the spesh log diff tool may be a bit b0rken at the moment :(
17:55 brrt that is, i typically search for the relevant frame
17:56 brrt i'll add on your difficulties and argue that the moar-gdb.py tool also seems broken atm :-)
17:57 FROGGS I just compared both logs (good and bad) using diff -u
17:58 brrt nah, that's probably not going to work
17:58 FROGGS good is 20549273 bytes, bad is 18869184
17:58 brrt ok, weird
17:58 brrt that seems a large difference (or my head is counting a digit to many on the good side)
17:59 FROGGS "only" the first 152721 lines are equalish
18:00 FROGGS 20_549_273 vs 18_869_184
18:01 timotimo brrt: i think i didn't adapt to the changes in the str ref branch
18:01 brrt ah i see
18:02 brrt i haven't seen what those changes are yet
18:02 timotimo it's a complete rewrite of the string code, pretty much :)
18:02 timotimo only leaving a few function signatures the same
18:02 timotimo can you tell me what piece of moar-gdb seems broken?
18:05 brrt i can try
18:05 brrt i can give you where the error comes from, at least
18:06 timotimo thanks
18:06 brrt hmm, not that easy it seems, i just get the error ' There is no member named flags'
18:06 brrt bbiab
18:07 klaas-janstol joined #moarvm
18:09 timotimo yeah, flags is now called "storage_type"
18:20 FROGGS okay, I learned that I only have to look at the spesh log of the bad version using the spesh_diff tool
18:21 FROGGS sadly the subroutine I'm searching for is not listed
18:28 woolfy left #moarvm
18:29 klaas-janstol joined #moarvm
18:59 jnap joined #moarvm
19:04 brrt joined #moarvm
19:07 dalek MoarVM/moar-jit: 7694ea9 | (Tobias Leich)++ | tools/ucd2c.pl:
19:07 dalek MoarVM/moar-jit: follow latest string refactor in source-gen script
19:07 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/7694ea914a
19:07 dalek MoarVM/moar-jit: 339d547 | (Tobias Leich)++ | / (2 files):
19:07 dalek MoarVM/moar-jit: add char name lookup aliases (LF,FF,CR and NEL)
19:07 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/339d547cdd
19:07 dalek MoarVM/moar-jit: 503f76a | (Tobias Leich)++ | src/strings/ops.c:
19:07 dalek MoarVM/moar-jit: RT #122341 handle all line separators
19:07 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/503f76ac8b
19:07 synopsebot Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=122341
19:07 dalek MoarVM/moar-jit: cadda24 | (Bart Wiegmans)++ | / (3 files):
19:07 dalek MoarVM/moar-jit: Merge remote-tracking branch 'origin/master' into moar-jit
19:07 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/cadda24a8b
19:07 dalek MoarVM/moar-jit: e0653b1 | (Bart Wiegmans)++ | src/jit/ (4 files):
19:07 dalek MoarVM/moar-jit: Add getwho
19:11 carlin joined #moarvm
19:30 brrt https://gist.github.com/bdw/554ea2b9ba17552babcd fix for moar-gdb pretty printing woes :-)
19:30 brrt timotimo ^^
19:30 brrt i can push it to master just as soon as you say the word
19:31 brrt mule complained about the codec ut8 by the way, insisting i call it utf-8
19:50 klaas-janstol joined #moarvm
20:03 FROGGS brrt: what word do you mean? please?
20:09 brrt more like 'looks good' or 'not totally wrong probably' or 'ok fine' :-)
20:09 brrt any word other than 'aaaaargh'
20:10 brrt well, i'll push it, you can revert it if you want
20:10 FROGGS okay
20:11 dalek MoarVM: d9fa779 | (Bart Wiegmans)++ | tools/moar-gdb.py:
20:11 dalek MoarVM: Updated moar-gdb.py for new structure of MVMString
20:11 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d9fa779ba1
20:11 FROGGS ahh, you just merge that
20:12 brrt that's actually directly on master :-)
20:34 tadzik joined #moarvm
20:40 sergot night o/
20:42 brrt night sergot
20:42 tadzik good knight sergot
20:47 brrt i've something that looks speshbuggy - or at least, that i can't readily explain
20:52 brrt oh, blimey, it's inlining probably
20:54 brrt .ask jnthn if this is normal and expected: https://gist.github.com/bdw/e5b606499aa6435f7e72
20:55 FROGGS brrt: go to #perl6
20:55 brrt good point
20:59 FROGGS Heap corruption detected: pointer 0x604638 to past fromspace :o(
21:02 brrt ehm, in moar-jit or just in general?
21:03 brrt and doing what?
21:04 brrt FROGGS_: i'm interested because i need to know if this is caused by moar-jit or if this is a general problem
21:05 japhb_ joined #moarvm
21:10 brrt also, if i'm looking at create right, we can / probably should / do better wrt to the boxing ops
21:13 FROGGS brrt: this little thing, in moar/master: https://gist.github.com/anonymous/0873fd7dd630a9deb6f2
21:13 FROGGS seems like flip is to blame
21:15 brrt let me see
21:15 brrt that's p6 code isn't it?
21:15 brrt ok, interesting
21:16 FROGGS it is
21:16 FROGGS when I dont get the past-fromspace, then cont at src/core/interp.c:1247 is garbage
21:17 FROGGS line 1247 is op(assign)
21:17 brrt any way i can trigger flip that you know of in nqp?
21:17 FROGGS nqp-m: say(nqp::flip("hurz"))
21:17 camelia nqp-moarvm: OUTPUT«zruh␤»
21:19 brrt right :-)
21:20 brrt hmm flip_s can't be responsible for my bug, because it isn't compiled yet
21:22 * TimToady wasn't using --enable-jit when he hit that bug
21:22 TimToady so I doubt it's a jit bug
21:22 FROGGS and it still explodes when I remove the gather/take
21:23 FROGGS my nursery size is 1024 right now btw
21:25 FROGGS hmmm, without spesh I get: Internal error: zeroed target thread ID in work pass
21:31 brrt it's a string bug probably
21:34 carlin those openBSD problems I reported earlier... rakudo builds fine as root, but dies building as a non-root user
21:37 brrt funny
21:37 brrt weird
21:38 FROGGS that sounds like es we might have problems loading the perl6_ops lib we just built
21:40 * brrt is too tired for this now, will work on the jit-specific memory corruption tomorrow
21:41 brrt left #moarvm
21:42 dalek MoarVM/moar-jit: 1258811 | (Bart Wiegmans)++ | src/jit/graph.c:
21:42 dalek MoarVM/moar-jit: Add flip
21:42 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/1258811914

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