19:14 | <shu> | Mathieu Hofman: did you have a proof of concept for the object reference leak for Error.prepareStackTrace ? i'm trying to write a counterexample and am not sure how it's possible, actually |
19:15 | <shu> | because wrapped functions (in both directions) throw fresh TypeErrors if the wrapped function throws, the fresh TypeErrors don't have outside stacks anyway |
19:16 | <shu> | as specced today it doesn't seem to me like we can ever get striped stacks at all, just because of how it falls out of the fresh error creation |
19:18 | <shu> | if, for DX reasons, we start wanting to stitch together .stacks even through the fresh error creation, then this may become a problem |
19:20 | <littledan> | as specced today it doesn't seem to me like we can ever get striped stacks at all, just because of how it falls out of the fresh error creation |
19:20 | <shu> | how do you get a striped stack? |
19:20 | <shu> | sorry, more specifically, how do you get a striped .stack ? |
19:20 | <shu> | where should i throw a new Error() to get a striped .stack ? |
19:21 | <shu> | (you can clearly get striped execution stacks, i'm just talking about the observable .stack thing v8 does) |
19:23 | <littledan> | from https://v8.dev/docs/stack-trace-api I don't understand why the .stack wouldn't contain at least function names that are striped |
19:23 | <shu> | because of step 11 here: https://tc39.es/proposal-shadowrealm/#sec-ordinary-wrapped-function-call |
19:24 | <shu> | any time you call a wrapped function, there's an implicit try-catch around it, and you throw a new TypeError |
19:24 | <shu> | and that new TypeError doesn't have the .stack of the original error |
19:24 | <shu> | like, this is the same reason for the .message normative change, because that was also just disappeared |
19:24 | <littledan> | that's not what we've been talking about; this is immediately when the error is thrown, if you observe its .stack, you can see it's striped |
19:25 | <littledan> | before it crosses any boundaries |
19:25 | <shu> | wait what |
19:25 | <littledan> | I'm not claiming this is a reference leak |
19:25 | <littledan> | but this is what the presentation last meeting was about |
19:26 | <littledan> | like you do /* inside of a deep striped stack context */ try { throw new Error() } catch (e) { console.log(e) } |
19:26 | <littledan> | rather than catching after you've moved out into a different place |
19:26 | <littledan> | if you did that in conjunction with patching prepareStackTrace , that's where any hypothetical reference leak would be |
19:28 | <shu> | ah, right |
19:29 | <shu> | i guess v8's current implementation with its "context switching" (what it calls global scopes) is preventing any striped stacks from showing up at all |
19:29 | <shu> | i wonder what it does for iframes |
19:29 | <shu> | like, in either direction |
19:36 | <shu> | hm, iframes display the striped stacks fine |
19:36 | <shu> | sorry for the noise, i need to investigate further |
19:36 | <littledan> | well, only same-origin iframes can call each other's functions, so it's not really a same-origin-model barrier, just a "context switch" |
19:37 | <shu> | right, i imagine an origin nonce or something isn't being passed |
19:59 | <shu> | ah doh, it's just d8 being buggy and forgetting the set the same security token as the incubator realm |
19:59 | <shu> | sorry for all the confusion |
21:41 | <Mathieu Hofman> | shu: I'm not sure where the confusion stemmed from by as littledan said, just creating an error inside the shadow realm and observing its stack there is the issue. Here is a potential example:
|
21:44 | <shu> | Mathieu Hofman: the confusion was my not observing any striped stacks in practice, which turned out to be an implementation issue with the d8 testing shell |
22:35 | <littledan> | sorry but my production environment depends on the current d8 observable behavior, you can't change that |