Namely: JetpackChild.cpp : ReportError Handle.h : GetParent, CreateHandle xpcconvert.cpp: NativeInterface2JSObject/CreateHolderIfNeeded xpccomponents.cpp : CallOrConstruct, GetGlobalForObject nsNPAPIPluggin.cpp: _evaluate ObjectWrapperParent.cpp : jsval_from_PObjectWrapperParent nsJSEnvironment.cpp : nsJSContext::SetProperty nsDOMClassInfo.cpp : nsWindowSH::GetProperty nsScriptableRegion.cpp : GetRects dmandelin and I found these while investigating bug 605290: several of these flow into 'jsval' IDL outparams which would then explode in JSCompartment::wrap when it was called by GatherAndConvertOutparams in XPCNW::CallMethod fixing this will fix that bug.
Oh duh, I just remembered while putting Scott to sleep that JSVAL_IS_OBJECT === js::Value::isObjectOrNull OBJECT_TO_JSVAL === js::Value::setObjectOrNull so all the above cases aren't actually bugs. (For fatvals, I didn't want to change the semantics of these public API functions since that would effectively force embeddings (incl. mozilla) to do a whole-program data-flow analysis.) So it looks like, for bug 605190, the princess is in another castle.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Well, the bug isn't totally invalid; there is one pretty central site using the internal API which doesn't check for null.
Attachment #501760 - Flags: review?(gal)
Summary: there are a bunch of places NULL can flow into OBJECT_TO_JSVAL → JSCompartment::wrap missing oom check
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.