github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:00 reportable6 left 00:03 reportable6 joined 01:18 MasterDuke left 04:59 pamplemousse joined 05:12 brrt joined 05:29 brrt left 06:00 reportable6 left 06:03 reportable6 joined 06:52 MasterDuke joined 07:32 robertle left 07:33 pamplemousse left 07:54 robertle joined 08:00 sena_kun joined 08:02 zakharyas joined
timotimo i wonder if jimmyz will come visit again at some point 08:13
MasterDuke i've seen him randomly point out problems in commits, but his main contributions were before i was around. what did he work on? 09:05
timotimo i don't remember very well, but i think it was basically "everything"? 09:06
back when there wasn't too much different stuff in moarvm anyway ;)
MasterDuke timotimo: btw, was this patch and output at all useful? if so, should it be incorporated in for reals? gist.github.com/MasterDuke17/76864...3ad1be78c4
cool
timotimo it seems useful, yeah 09:07
without that, it'll just say that it lives in the nursery or something?
may have to look if the block ought to be destroyed, too, when the object gets moved or deleted 09:08
MasterDuke as part of the extra valgrind support? or in general? 09:11
timotimo the extra valgrind support
MasterDuke after the VALGRIND_PRINTF_BACKTRACE? 09:16
timotimo hm?
MasterDuke destroying the block
timotimo no, in regular operation
the blocks are being registered whenever objects are allocated, but nothing further is done when the objects move or get freed
so later on you could get false positives
MasterDuke ah 09:17
easy place to do that? 09:18
timotimo oof. is there an "actually this block has moved" client request? 09:21
MasterDuke in valgrind? i have no idea. i think i pretty much just copied something you said into vim 09:23
doesn't look like it if i'm reading valgrind.org/docs/manual/mc-manual....r-commands correctly 09:32
just the DISCARD to stop watching it 09:33
timotimo oof, yeah, we'd have to keep that value around 09:34
the block handle
MasterDuke add it to the obj->header if MVM_VALGRIND_SUPPORT? 09:35
timotimo that could force a recompile of rakudo whenever moar gets recompiled with valgrind support on or off 09:37
09:40 MasterDuke left 09:52 MasterDuke joined
MasterDuke i guess that could be annoying, but i don't know if anybody uses valgrind support all that frequently 09:54
any better way though?
timotimo in theory, the bump-the-pointer-allocation scheme of the nursery would allow us to just put the number after the object 09:55
MasterDuke and then just increase the size of the bumps by the size of that number? 09:56
timotimo yeah
and look all over for edge cases that may be easy to miss :)
MasterDuke sounds like fun 09:57
10:21 Kaiepi left, Kaiepi joined 10:29 MasterDuke left
timotimo googleprojectzero.blogspot.com/201...-hole.html - impressive 10:39
11:02 cygx joined
cygx o/ 11:02
gist.github.com/cygx/70a8ab6762459...abf067100c 11:03
comments?
11:04 zakharyas left 11:09 pamplemousse joined
cygx hm... 11:24
there's also a findsym op that might serve the same purpose ina different way 11:25
it's apparently not hooked up to anything, though 11:26
timotimo that sounds like a nativecall thing 11:27
cygx o/ 11:53
11:53 cygx left 12:00 reportable6 left, reportable6 joined 12:03 lucasb joined 12:35 zakharyas joined 12:44 MasterDuke joined 14:41 robertle left 16:15 robertle joined 16:30 chloekek joined 16:34 zakharyas left 16:37 mst left, mst joined, ChanServ sets mode: +o mst 16:44 mst left, mst joined, card.freenode.net sets mode: +o mst 17:18 chloekek left 18:00 reportable6 left, TimToady left, reportable6 joined, TimToady joined 20:28 zakharyas joined
timotimo ===SORRY!=== 21:19
P6opaque: no such attribute '$!restart' on type NQPMu in a NQPMatch when trying to get a value
now here's one i haven't seen yet
(this is in mqtt's test while trying to profile under valgrind)
21:24 sena_kun left 21:25 zakharyas left
timotimo oh, i don't have valgrind support on, only telemeh 21:25
MasterDuke i didn't notice any difference with the normal valgrind support (i.e., adding `--valgrind`) 21:26
timotimo i tried to make it better :( :( 21:27
MasterDuke that sentence starts out so promising...
timotimo ==30887== Invalid read of size 4 21:36
==30887== at 0x4BA19AF: add_type_to_types_array (instrument.c:440)
well
i'm not sure i understood what you meant by that sentence, MasterDuke 21:45
MasterDuke "i tried to make it better" is kind of good. but then ":( :("...not so much 21:46
timotimo the sentence before that 21:49
bleeehhhh why is my hard drive full again 21:51
oh, there's the answer 21:52
core dumps
lizmat
.oO( nuke all the precomps )
MasterDuke oh. i don't think i got any different error messages or more useful info when i reran profiling the mptt tests under valgrind before or after compiling moarvm with --valgrind
i think that's why you helped my come up with that patch in the gist 21:53
timotimo mhh
welp, maybe i can at least find out why the test sometimes dies with that SORRY
MasterDuke ++timotimo
22:03 Kaiepi left, Kaiepi joined 22:05 Kaiepi left, Kaiepi joined
timotimo i only had to "reverse-continue" "call MVM_dump_backtrace(tc)" about a thousand times to get here, but i've reached the spot the exception was actually thrown 22:07
i should have had a different breakpoint
probably one that gets hit when an exception is thrown >_<
MasterDuke you didn't have it at MVM_exception_throw_adhoc? 22:09
but did you find something good?
timotimo i had it at MVM_profile_enter 22:13
not yet, i've only just reached the spot where things happen
aha, this is very strange 22:31
MasterDuke strange fixable? or strange this-defies-all-known-laws-of-physics? 22:32
timotimo well, the code we have here is super simple 22:33
it's method "ast" of something 22:34
we've got a speshed candidate
pulls the argument that comes in, grabs the type from a spesh slot, calls getattr_o on the object with the type and the string '$!made'
only problem is
that spesh slot contains NQPMu rather than Perl6::Grammar
22:35 pamplemousse_ joined
timotimo oh no 22:35
MasterDuke no surprise it doesn't have a '$!made' then, but how did an NQPMu get there? 22:36
timotimo i didn't get the "when" before i searched backwards for the place where that value gets set
MasterDuke well, i'm off to bed, but good luck figuring stuff out 22:39
22:39 pamplemousse left
timotimo 249121 in case you were wondering :P 22:40
MasterDuke that's a memory address? 22:42
22:43 dogbert17 left
timotimo no, event number from "rr replay" 22:43
MasterDuke ha. not small
timotimo huh, this spesh plan is kind of weird 22:51
MasterDuke cause or symptom of the crash when profiling this example? 22:53
timotimo ok, so here's how i currently understand it 22:54
the optimization that causes the NQPMu spesh slot to be written is optimize_getlex_per_invocant 22:55
22:55 MasterDuke left
timotimo which means that we know the type of the thing because we're currently building a specialization for a method being called on that exact type 22:55
but the slot we're finding for this specific instruction, i.e. what was logged at that spot before, has 8 different results
the last one is, i think, the one we want 22:56
but the code currently just checks if the number of available logged types is nonzero
i think it should maybe check if the count is exactly 1
because it then just goes and takes the first type there
22:59 MasterDuke joined
MasterDuke that doesn't sounds quite correct 22:59
timotimo i could be misunderstanding 23:02
and of course now i can't reproduce the problem any more 23:03
MasterDuke ugh, time to actually tear myself away 23:04
later...
timotimo seeya 23:09
oh, it's probably sensitive to profiling! 23:10
so it could also be that the profiling causes annotation bytecode offsets to shift?! 23:18
that would be the worst
[rr 15283 518790]spesh: would have specialized on invocant with 3 types available 23:24
[rr 15283 518792]NQPMu[rr 15283 518794], [rr 15283 518796]NQPRegex[rr 15283 518798], [rr 15283 518800]NQPMatch[rr 15283 518802]
now the thing is i actually didn't let it do that, so i can't actually see if that would have been the crash
now how does it record an NQPMu in there in the first place? no idea! 23:26
gist.github.com/timo/1332e5242e3f1...9dcfa3a251 23:33
it looks really very suspiciously like what i found was exactly the culprit
i'm considering bedtimen ow 23:34