|
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 | ||