|
00:59
JRaspass left,
JRaspass joined
|
|||
| ugexe | gist.github.com/ugexe/00b8c4cdbc2a...85d91b7fd4 suggests a root cause and solution to | 01:21 | |
| github.com/MoarVM/MoarVM/issues/1750 The proposed solution does appear to fix the issue, and it does pass spectest. It adds a fallback for when body.outer is NULL to the sp_getlexvia_* ops, which surprised me as my initial naive thought was we'd have to just disable inlining when code->body.outer == NULL && static_code->body.outer == NULL | |||
|
02:54
japhb joined
04:02
japhb left
04:34
japhb joined
06:14
japhb left
10:27
[Coke] left
10:29
[Coke] joined
11:11
librasteve_ left
|
|||
| timo | we should definitely prefer preventing a frame from being inlined with sp_getlexvia_* if that situation occurs | 12:20 | |
| a lot of the benefit of spesh is "strength reduction", and giving sp_getlexvia_* the "power" to check for and cause autoclosing may be a cost we don't want to pay | 12:21 | ||
| I got quite annoyed with the gist you pasted with the jit bug findings; the exprjit is now dead code so spending any time on it, except if someone wanted to pick it up and develop it further, is wasted. the "Subtle future hazard" from the last point is just bonkers | 12:36 | ||
| maybe I didn't pay enough attention to the fact that you said "I haven't really looked at the other two" and had the expectation that you were giving the output with some amount of vetting | 12:37 | ||
| without vetting it feels like the same thing the curl maintainers experienced with bogus vulnerability reports, you spend more time filtering out the nonsense than you save by getting stuff discovered for you | 12:50 | ||
| ugexe | I’ll just stop this experiment and go back to my occasional scanning of irc or prs :) | 13:28 | |
|
14:01
librasteve_ joined
|
|||
| patrickb | I'm hunting another moar debugserver issue. | 16:07 | |
| It tries to access a null pointer while reading the value of an outers lexical ($_). | 16:08 | ||
| github.com/MoarVM/MoarVM/blob/main...er.c#L2203 <- here `result` is a non-null pointer, result->o is null. | 16:11 | ||
| github.com/MoarVM/MoarVM/blob/main...er.c#L2216 <- here `result` is overwritten with null | 16:14 | ||
| github.com/MoarVM/MoarVM/blob/main...er.c#L2222 <- I'm messed a bit with the code, the MVM_frame_vivify_lexical here would change result->o to a non-null pointer (but it's never called) | 16:21 | ||
| That `result` is then accessed a bit further in the execution. | 16:22 | ||
| This makes me think there is an issue with debug_locals. But I'm missing loads of context here. @timo Can you give me a quick primer on debug_locals? (Or any hints on how to best debug this further.) | 16:25 | ||
| lizmat | timo ^^ | 16:26 | |
| patrickb | I'm AFK for a while, but will most probably be back in a few hours. I'm glad for any hints. | 16:28 | |
|
17:11
japhb joined
17:48
Voldenet left,
Voldenet joined
|
|||
| timo | debug_locals is when some part of rakudo's optimizer (static) has lowered a lexical to instead be stored as a local, but we keep the name of the lexical around for the benefit of debugserver users and we remember what the number of the local is that it's stored in | 19:28 | |
| i had an extra long workday today i'm completely out of energy :| | 20:21 | ||
| it's not critical to just chuck the debug locals support for the moment, just pretend there are none, that will just cause some lexicals to not show up in the debugger when the optimizer has removed them | |||
| patrickb | No worries. Enjoy your evening! I'll look around a bit myself. Maybe I'll be able to dig something up. And thanks for the explanation! | 20:23 | |
|
20:23
ugexe left
|
|||
| timo | i'm not 100% sure how vivifying lexicals works in case a lexical was turned into a local, or why the case might happen that a lexical is "kept around" even though it was turned into a local | 20:25 | |
| patrickb | (I have to admit that I don't know what a local is.) | 20:34 | |
| timo | oh | 20:49 | |
| they are called "registers" in other parts of the compilr | |||
| frames have a work area and an env, env is where lexicals live and the env lives longer than the frame for reasons of closures and such, but the env is freed when a frame returns | |||
| patrickb | that should read "but the work area is freed when a frame returns", right? | 21:47 | |
| timo | oh, yes | 21:48 | |
| patrickb | registers is where all the actual processing happens (i.e. opcodes operate on registers), right? And then there are opcodes that allow copying a lexical into a register for further processing. Lexical to local lowering then means that the lexical is not accessed from a place we can't reason about and we then keep it's vales entirely in a register and the lexical effectively ceases to exist. About right? | 22:05 | |