github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:10 lizmat left
timotimo MasterDuke: oh, i meant to ask you if dmesg showed anything? 00:15
i seem to recall a lot of work to make EVAL threadsafe 00:16
00:30 bisectable6 left, bisectable6 joined 00:32 bisectable6 left, bisectable6 joined 00:33 bisectable6 left, bisectable6 joined 02:33 Kaypie left, Kaypie joined 03:04 Merfont joined 03:07 Kaypie left
MasterDuke .tell timotimo nothing relevant in dmesg 03:47
yoleaux MasterDuke: I'll pass your message to timotimo.
MasterDuke .ask timotimo is there any sort of debugging i can turn on (or add) to help figure out what's going on? 03:53
yoleaux MasterDuke: I'll pass your message to timotimo.
03:53 klapperl joined 05:40 lizmat joined 05:47 domidumont joined 05:57 brrt joined 06:13 domidumont left 06:14 domidumont joined
brrt . 06:17
Geth MoarVM: 2249d68802 | (Bart Wiegmans)++ | src/jit/x64/emit.dasc
[JIT] Move lexprimspec to proper emitter

Was in emit_block_branch, has to go to emit_primitive (isn't a branching operator). Oops!		 06:19
06:26 domidumont left 06:37 robertle joined 06:43 domidumont joined 06:49 Ven`` joined 07:04 zakharyas joined 07:35 Ven`` left, Ven` joined 07:45 Ven` left, Ven`` joined 08:04 zakharyas left 08:17 Ven` joined, Ven`` left 08:20 zakharyas joined
Geth MoarVM/jit-moar-ops: 813bba6748 | (Bart Wiegmans)++ | 2 files
[JIT] Implement ctxouter
 08:35
brrt gist.github.com/shafik/848ae25ee20...ee272a58f8 - if i'm reading this correctly using a union for type punning is legit in C 08:48
08:52 Ven` left
brrt stackoverflow.com/questions/256648...pe-punning and this says so as well 08:53
phew, C is sane
09:03 Ven`` joined 09:04 zakharyas left 09:07 zakharyas joined
brrt lets finally nail down throwpayloadlexcaller 09:08
samcv brrt: so tell me more about this issue 09:09
that may need a new release
brrt github.com/MoarVM/MoarVM/commit/2249d68802 09:11
this thing
I added the JIT of `lexprimspec` to the wrong emitter function
now if lexprimspec is actually JIT compiled, it will fail at runtime
samcv ah 09:13
which causes segfaults?
brrt no, panics
not as bad as segfaults, but still bad
anyway, i'm off for lunch 09:18
this is an oldish bug though
09:23 brrt left 10:08 zakharyas left, zakharyas joined 10:10 Ven`` left 10:14 brrt joined
jnthn aha...finally tracked down a slowdown 10:52
I was grepping for BAIL in the jit log. Turns out that it was bailing but differently
Unexpected opcode in invoke sequence: <speshresolve> 10:53
Which can happen in code that was never reached 10:54
11:04 zakharyas left
Geth MoarVM: a75090c60e | (Jonathan Worthington)++ | src/spesh/threshold.c
Lessen the number of spesh threshold levels

When something tiny called something a bit bigger, we could end up with the call there not being able to specialize into a fast resolve due to the callee potentially not being hot enough yet. Once things get over a certain size that'll be noise, but there's plenty of cases
  (tiny forwarding subs/methods delegating to slightly bigger impls)
that could benefit. So, collapse the lower levels to a single one.		 11:05
jnthn That said, speshresolve that survives into the specialized code really wants a spesh op 11:06
Since the index would "move" otherwise 11:07
11:08 zakharyas joined 11:19 zakharyas left 11:39 Ven`` joined 11:48 Ven`` left, Ven`` joined
dogbert17 .seen timotimo 11:54
yoleaux I saw timotimo 00:39Z in #perl6: <timotimo> i wonder if we have to put &lt; and &gt; instead of < and > to render it correctly everywhere
dogbert17 .seen timotimo's cats
yoleaux I haven't seen timotimo's cats around.
dogbert17 trying to profile something while at the same time enabling MVM_CROSS_THREAD_WRITE_LOG seems to be a really bad idea 11:55
MoarVM panic: Profiler lost sequence - at SETTING::src/core/Deprecations.pm6:30 (/home/dogbert/.rakudobrew/moar-master/install/share/perl6/runtime/CORE.setting.moarvm:report) 11:56
12:02 undersightable6 left 12:03 Merfont is now known as Kpimov, Kpimov is now known as Kaiepi, undersightable6 joined 12:14 lizmat left 12:32 Ven` joined 12:34 Ven`` left 12:42 zakharyas joined 13:04 zakharyas left 13:05 zakharyas joined 13:35 lizmat joined 13:36 Ven` left
timotimo probably two instrumentations that aren't compatible in some way 13:42
yoleaux 03:47Z <MasterDuke> timotimo: nothing relevant in dmesg
03:53Z <MasterDuke> timotimo: is there any sort of debugging i can turn on (or add) to help figure out what's going on?
dogbert17 timotimo: very easy to repro, just try: MVM_CROSS_THREAD_WRITE_LOG=ctw.log perl6 --profile -e '' 14:03
timotimo yeah 14:04
i haven't considered making that work yet, or even tryign it
14:07 zakharyas left 14:08 zakharyas joined
dogbert17 I tried it because I wanted to see if [Coke]'s bug from yesterday might stem from some threading problem, i.e. gist.github.com/dogbert17/ade09129...a38f5c7b6f 14:09
timotimo oh, i didn't notice there's a --profile in the original 14:10
dogbert17 :)
timotimo does it not crash if --profile is removed?
oh, perhaps call MVM_dump_bytecode(tc) would be interesting, too 14:12
dogbert17 I can do that
here goes :-) gist.github.com/dogbert17/ba488668...dcdeda81dc 14:13
timotimo and you say check is a null pointer there? 14:14
dogbert17 Cannot access memory at address 0x8 14:15
if I print *check
this one is nasty in that it doesn't happen every time the code is run 14:16
Kaiepi this is minor, but is making IO::Socket::Async.native-descriptor return the socket's fh instead of -1 worth pullreqing? 14:19
timotimo it'd be interesting to know what it had just invoked before the crash
because it looks like an integer is returned and just blindly put into an object register
OSLT
14:20 Ven`` joined
dogbert17 OSLT ? 14:21
timotimo or something like that
dogbert17 aha, can that be done from gdb?
figuring out what was invoked that is
timotimo with a bit of fiddling, i guess. or record execution with rr and do a few steps backwards 14:22
you can look at the object that's in spesh slot 34, which will be something invokable, and you'd have to dig deep to find the static frame that it belongs to, though there could be further indirection :| 14:23
dogbert17 that sounds difficult 14:24
dogbert17 is afk for a while (food) 14:25
14:36 lizmat left 14:48 domidumont left 14:49 domidumont joined 14:57 domidumont left
brrt grumbles about the completely evil state machine in search_frame_handlers_lex 14:58
dogbert17 notes that rr doesn't work on a Ryzen cpu 15:00
brrt i don't understand what's going wrong with Inline::Perl5 :-(
when i implement throwpayloadlexcaller
timotimo dogbert17: even with -n? 15:01
dogbert17 FATAL /build/rr-jR8ti5/rr-4.1.0/src/PerfCounters.cc:133:get_cpu_microarch() errno: 0 'Success'] 15:02
-> CPU 0xf10 unknown.
timotimo ah, damn 15:03
github.com/mozilla/rr/issues/2034 - i guess?
15:04 zakharyas left
timotimo it's supposed to recognize AMDRyzen, but only checks for 0xf10, not 0xf20 15:05
could be worth a patch.
but it does say that if you have a ryzen, rr will be unreliable 15:06
dogbert17 yeah, in the meantime I added MVM_SPESH_BLOCKING=1 and now it fails at a different point
here github.com/MoarVM/MoarVM/blob/mast...erp.c#L222 15:08
15:08 Ven`` left
dogbert17 and once, with MVM_SPESH_BLOCKING=1, it failed with 'Unhandled exception in code scheduled on thread 4 - const_n32 NYI' 15:09
timotimo that's just like when the profiler's instrumentation got turned off 15:12
it replaced one version of the bytecode with another and so it hit a bogus position in the bytecode and started interpreting arguments as opcodes 15:13
15:15 brrt left
dogbert17 I'm trying to get valgrind to output something of value but so far without success :( 15:15
15:17 lizmat joined
Geth MoarVM: stmuk++ created pull request #879:
Use clang with OpenBSD since their ancient gcc creates a moar which can't generate NQP anymore. See #878		 15:21
timotimo can you check if the instrumentation barrier is hit around that point? 15:23
dogbert17 how do I do that? 15:24
timotimo hm, setting a breakpoint is the first step, but it's not so easy to see if the problem comes "soon" after that
i'll be afk for a bit 15:25
dogbert17 I'll continue with valgrind in the meantime 15:27
15:31 robertle left
Geth MoarVM: Kaiepi++ created pull request #880:
Expose file descriptors of IO::Socket::INET instances		 15:52
16:21 MasterDuke left 16:23 Kaiepi left, Kaypie joined 16:27 Ven`` joined 16:28 Ven`` left 17:06 ggoebel left 17:07 AlexDaniel left 17:19 domidumont joined 17:21 ggoebel joined 17:54 AlexDaniel joined
dogbert17 timotimo: I tried another, smaller, program instead and got some output from asan which might be of some use 18:34
gist.github.com/dogbert17/397a596a...06a2b0a72e
18:44 robertle joined 19:04 domidumont left 19:17 AlexDaniel left 19:35 brrt joined
timotimo that's some nonsense :) 19:41
dogbert17 damn :) 19:51
timotimo looks like the instruction pointer went off into lala land 19:52
dogbert17 at least the program is short, a variant of one posted by MasterDuke previously 19:53
it bugs out in different ways, most often with 'MoarVM panic: Profiler lost sequence' 19:54
timotimo is it always with the profiler active? 19:55
dogbert17 yes, if you mean --profile
it always works with valgrind 19:56
timotimo and it doesn't crash if the profiler isn't active? 19:57
dogbert17 correct 20:00
timotimo that's helpful to know
i wonder if it uses run_profiled for the generated code
can you breakpoint MVM_profile_instrumented_start and see if it is called more than once? 20:02
dogbert17 sure 20:03
it's called once, then it crashes when I (c)ontinue 20:04
timotimo and does the _end version of that get called at all? 20:05
dogbert17 let's see 20:06
the answer seems to be no
it hits _start once an then borks 20:07
*and
20:09 AlexDaniel joined 20:20 lizmat left 20:21 Kaypie is now known as Kaipie 20:22 Kaipie is now known as Kaiepi 20:26 ggoebel left 20:43 brrt left 20:50 ggoebel joined 20:51 Kaypie joined, Kaiepi left 20:58 Kaypie is now known as Kaiepi 21:06 lizmat joined 21:28 hoelzro joined 22:24 Kaiepi left 22:25 Kaiepi joined 23:16 MasterDuke joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!