github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
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.
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
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
brrt stackoverflow.com/questions/256648...pe-punning and this says so as well 08:53
phew, C is sane
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
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
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
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
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
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
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
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?
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
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
dogbert17 I'm trying to get valgrind to output something of value but so far without success :( 15:15
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
Geth MoarVM: Kaiepi++ created pull request #880:
Expose file descriptors of IO::Socket::INET instances
15:52
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
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