1331748 - Ensure non-CpowEntry CPOWs are always unwrapped upon receipt

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Andrew McCreight [:mccr8]]

In bug 1330018, we saw that failing to unwrap a CPOW sent via the message manager can cause leaks. That bug only fixed the case where a CpowEntry isn't unwrapped. There are a number of other places we can send CPOWs, all in PJavaScript. I'll look over their uses and see if there are any places we can fail to unwrap a CPOW.

Types that can contain CPOWs:
* RemoteObject (base case we care about)
* ObjectVariant (union with RemoteObject case)
* ObjectOrNullVariant (union with ObjectVariant case)
* JSVariant (union with ObjectVariant case)
* ReturnException (struct with JSVariant field exn)
* ReturnStatus (union with ReturnException case)
* JSParam (union with JSVariant case)
* GetterSetter (union with ObjectVariant case)
* PPropertyDescriptor (struct with ObjectOrNullVariant field obj, JSVariant field value, GetterSetter fields getter and setter)

PJavaScript messages that get or receive CPOWs:
* GetPrototype, GetPrototypeIfOrdinary (ObjectOrNullVariant)
* Get, Set, HasInstance (JSVariant)
* CallOrConstruct (JSVariant and JSParam)
* GetPropertyDescriptor, GetOwnPropertyDescriptor, DefineProperty (PPropertyDescriptor)

Comment 1

[Andrew McCreight [:mccr8]]

There are also a lot of methods that return a ReturnStatus (as you might expect):
  http://searchfox.org/mozilla-central/search?q=ReturnStatus&path=.ipdl

Comment 2

[Andrew McCreight [:mccr8]]

I looked over I think most of these places, and it seems good enough to me. The set up is a little fragile, in that in many places it relies on never sending an error ReturnStatus along with a CPOW, but that seems reasonable enough. This also ignores JS API stuff failing due to OOMs, which will also cause these leaks. Things could be improved a little by adding wrapper classes for everything, but that seems like a lot of hassle for questionable return.