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
Huh? How so?
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:

const child = new ShadowRealm();
child.evaluate(`
const originalPrepare = Error.prepareStackTrace;
Error.prepareStackTrace = function(error, structuredStackTrace) {
  for (const callSite of structuredStackTrace) {
    console.log(callSite.getFunctionName(), callSite.getFunction());
  }
  return originalPrepare(error, structuredStackTrace);
});
`);
const getStack = child.evaluate(`function() {
  try { null.error } catch (e) { return e.stack; }
}`);
console.log(getStack());
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