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