1367815 - Investigate whether proxies other than CCWs store a cross compartment pointer in their private slot

Status: RESOLVED FIXED

(Core :: JavaScript: GC, enhancement)

Description

[Jon Coppeard (:jonco)]

I didn't think this was supposed to happen but the assertion failures in bug 1365564 after the initial patch landed suggest that it does.

Comment 1

[Steve Fink [:sfink] [:s:]]

This seems scary. The odds of these sorts of things handling cross-compartment pointers correctly is extremely low.

Comment 2

[Jon Coppeard (:jonco)]

Attachment: bug1367815-cc-proxies

I couldn't figure out what was causing this.  This patch just adds a couple of assertions to catch this if it ever happens.

Comment 3

[Steve Fink [:sfink] [:s:]]

Comment on attachment 8873415 [details] [diff] [review]
bug1367815-cc-proxies

Review of attachment 8873415 [details] [diff] [review]:
-----------------------------------------------------------------

nice

Comment 4

[Jan de Mooij [:jandem]]

Comment on attachment 8873415 [details] [diff] [review]
bug1367815-cc-proxies

Review of attachment 8873415 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/vm/ProxyObject.cpp
@@ +92,5 @@
>      values->init(proxy->numReservedSlots());
>  
>      proxy->data.handler = handler;
> +    if (IsCrossCompartmentWrapper(proxy))
> +        proxy->setCrossCompartmentPrivate(priv);

Would it be possible to assert this in setCrossCompartmentPrivate? IsCrossCompartmentWrapper will add a bunch of overhead in opt builds (it's not inlined).

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9e5ac6fa7858
Add assertions to prevent proxies other than cross compartment wrappers from having cross compartment targets r=sfink

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9e5ac6fa7858