Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-10-27

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

All times shown according to UTC.

Time Nick Message
00:33 bloatable6 joined #moarvm
00:36 samcv the .tar.gz file contains our user info. not that it matters to me. but interesting. jnthn's releases have jnthn as the username in the tar and mine has samantha
00:36 Zoffix ⚠️⚠️⚠️⚠️⚠️⚠️⚠️ ❗❗❗❗ ❕❕❕❕
00:36 Zoffix
00:36 timotimo oh yeah tar tends to do that
00:36 Zoffix NOTICE: Main Development Branch Renamed from “nom” to “master”: http://rakudo.org/2017/10/27/main-development-branch-renamed-from-nom-to-master/
00:36 Zoffix
00:36 Zoffix ⚠️⚠️⚠️⚠️⚠️⚠️⚠️ ❗❗❗❗ ❕❕❕❕
00:43 samcv releas added to moarvm.org repo now
00:43 * timotimo does the tiniest dance
01:07 MasterDuke `MVMP6bigintBody *body    = get_bigint_body(tc, result);` complains `This representation (P6int) cannot unbox to other types (for type BOOTInt)`
01:08 MasterDuke when result is created like thus `MVMObject * const result = MVM_repr_alloc_init(tc, tc->instance->boot_types.BOOTInt);`
01:08 MasterDuke is BOOTInt not the right type to use there?
01:11 MasterDuke hmm, maybe i do want a result_type parameter
01:33 greppable6 joined #moarvm
01:57 ilbot3 joined #moarvm
01:57 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:14 Geth ¦ MoarVM: MasterDuke17++ created pull request #737: Create and JIT coerce_II op
03:14 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/737
05:32 Geth ¦ MoarVM: ugexe++ created pull request #738: Retry in certain cases of EINTR
05:32 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/738
06:20 domidumont joined #moarvm
06:27 domidumont joined #moarvm
07:09 domidumont joined #moarvm
07:13 lizmat joined #moarvm
07:19 patrickz joined #moarvm
08:10 zakharyas joined #moarvm
08:15 zakharyas joined #moarvm
08:21 zakharyas joined #moarvm
08:32 zakharyas joined #moarvm
08:35 Ven joined #moarvm
09:13 Ven joined #moarvm
09:26 zakharyas joined #moarvm
09:46 Ven_ joined #moarvm
10:09 Ven joined #moarvm
10:27 dogbert2 jnthn: does this gist give you any ideas? https://gist.github.com/dogbert17/6257f2d6d3b713207e31b6b260ef8a29
10:34 jnthn Not really
10:34 jnthn It'll need tracing back to the call arguments
10:37 Ven_ joined #moarvm
11:34 dogbert2 are there any parameters to MVM_spesh_arg_guard_run I should dump or perhaps a MVM_dump_backtrace?
12:02 dogbert2 jnthn, timotimo: I have stopped gdb at https://github.com/MoarVM/MoarVM/blob/master/src/spesh/arg_guard.c#L408, 'test' has suddenly become null. Are there any variables etc I should check?
12:09 dogbert2 (gdb) p *args
12:09 dogbert2 $1 = {o = 0x80803d0, s = 0x80803d0, i8 = -48 '\320', u8 = 208 '\320', i16 = 976, u16 = 976, i32 = 134742992, u32 = 134742992, i64 = 134742992, u64 = 134742992, n32 = 4,09304929e-34, n64 = 6,6571883365061916e-316}
12:18 dogbert2 (gdb) p *ag->nodes
12:18 dogbert2 $3 = {op = MVM_SPESH_GUARD_OP_CALLSITE, yes = 14, no = 12, {cs = 0x81dc1d8, arg_index = 49624, st = 0x81dc1d8, offset = 136167896, result = 136167896}}
12:50 zakharyas joined #moarvm
12:55 synopsebot joined #moarvm
12:57 synopsebot joined #moarvm
13:18 synopsebot joined #moarvm
13:41 zakharyas joined #moarvm
13:51 zakharyas joined #moarvm
15:11 timotimo we'd have to figure out where the null came from, i.e. what piece of code put a null into the arguments array
15:12 timotimo given how the "dump bytecode" function seems to put the -> at a semi-random place, that's not quite as easy i'm afraid
15:12 timotimo if we had an rr recording we could step back to the corresponding "enter frame" (which could mean going over a whole lot of leave/enter pairs)
15:12 timotimo and then trace it step-by-step
15:18 ggoebel joined #moarvm
16:37 greppable6 joined #moarvm
16:38 AlexDaniel joined #moarvm
17:19 domidumont joined #moarvm
17:42 dogbert17 timotimo: can a spesh log give any clues?
18:04 timotimo not likely
18:15 dogbert17 sigh, a difficult bug then, grr
18:18 timotimo hm. if you know exactly which spesh candidate from the spesh log is on the stack at each point, and you know which exact invocation has the broken args buffer, you can probably trace back what the value goes through?
18:18 bisectable6 joined #moarvm
18:18 benchable6 joined #moarvm
18:18 committable6 joined #moarvm
18:18 squashable6 joined #moarvm
18:18 unicodable6 joined #moarvm
19:24 robertle joined #moarvm
20:36 samcv good **
20:40 Zoffix \o
21:13 Geth ¦ MoarVM: 00c3211c5c | (Elizabeth Mattijsen)++ | 2 files
21:13 Geth ¦ MoarVM: Remove dependency on autodie
21:13 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/00c3211c5c
21:20 stmuk_ joined #moarvm
21:38 hoelzro joined #moarvm
22:07 lizmat .tell jnthn 'time while perl6 -e 'my $a = 0; await start { for ^10000 -> $i { cas $a, -> $b { $b + $i } } } xx 4'; do :; done' segfaults for me within the second generally when run in conjunction with a "TEST_JOBS=8 make spectest"
22:07 yoleaux lizmat: I'll pass your message to jnthn.
22:08 jnthn Arse, I thought I'd got those spectests clean :/
22:08 jnthn Under GC stressing
22:11 lizmat jnthn: I don't think it's GC stressing (if I understand that term correctly)
22:11 lizmat feels more like a race condition to me
22:11 lizmat as it doesn't crash if that code is just run by itself
22:12 jnthn Maybe, though a race alone isn't generally enough to trigger a SEGV
22:12 lizmat ok, if I increase from xx 4 to xx 8 it *does* crash by itself
22:13 lizmat with xx 7 it crashed after 37 seconds
22:14 jnthn Thread 4 "moar" received signal SIGSEGV, Segmentation fault.
22:14 jnthn [Switching to Thread 0x7fffef7fe700 (LWP 2183)]
22:14 jnthn 0x00007ffff775a222 in MVM_serialization_demand_object () from //home/jnthn/dev/MoarVM/install/lib/libmoar.so
22:14 jnthn o.O
22:14 lizmat does not ring a bell to me
22:14 jnthn That's a weird place to explode
22:15 lizmat well, if you run it again, maybe it'll explode somewhere else
22:15 lizmat I mean, with the #1202 code I get a MoarVM panic about heap corruption
22:16 jnthn Does it right there again
22:16 jnthn (gdb) p sc->body
22:16 jnthn $2 = (MVMSerializationContextBody *) 0x0
22:16 jnthn c'est le hosed
22:17 lizmat ok, so maybe we're on to something
22:19 lizmat 5m18.212s before it segfaulted
22:20 Geth ¦ MoarVM: 9ad1f5fc86 | (Jonathan Worthington)++ | src/6model/serialization.c
22:20 Geth ¦ MoarVM: Add missing MVMROOT around managed mutex acquire
22:20 Geth ¦ MoarVM:
22:20 Geth ¦ MoarVM: The mutex acquire may GC block and thus trigger GC, moving objects.
22:20 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9ad1f5fc86
22:20 lizmat pretty sure it happened because I was doing something else on the machine, that required one or 2 CPU's
22:20 lizmat whee!
22:21 jnthn GC-related bug, but depended on mutex acquisition timing, which would be naturally impacted by load
22:33 lizmat jnthn: the cas code still segfaults for me, quite quickly
22:33 lizmat the GH #1202 code so far has not
22:34 lizmat so I think Rakudo GH #1202 looks fixed by this fix
22:35 jnthn Hm, that fixed the cas code nicely for me. Odd
22:35 lizmat alas, the 1202 also crashed: MoarVM panic: Internal error: zeroed target thread ID in work pass  after 4m50
22:36 jnthn Guess that'll be something different, then
22:36 jnthn But not for me today
22:36 lizmat the GH #1202 code feels more stable now
22:37 lizmat so it may have helped anyways
22:37 jnthn Well, surely helped :)
22:37 jnthn I got a crash after a few runs before, and it kept on going for ages after the fix

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