| Summary: | ASSERT(isValidAllocation(bytes)) when ObjC API creates custom errors | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Joseph Pecoraro <joepeck> | ||||
| Component: | JavaScriptCore | Assignee: | Mark Hahnenberg <mhahnenberg> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | ggaren, joepeck, mhahnenberg | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Joseph Pecoraro
2014-02-14 13:46:55 PST
There are a number of create calls throughout the ObjC API. They will all need to be audited:
shell> ack 'create.*?Error' API/*.mm
API/JSValue.mm
784: *exception = toRef(JSC::createTypeError(toJS(context), "Cannot convert primitive to NSArray"));
800: *exception = toRef(JSC::createTypeError(toJS(context), "Cannot convert primitive to NSDictionary"));
API/ObjCCallbackFunction.mm
132: *exception = toRef(JSC::createTypeError(toJS(contextRef), "Argument does not match Objective-C Class"));
456: // (2) We're calling some JSC internals that require us to be on the 'inside' - e.g. createTypeError.
499: *exception = toRef(JSC::createTypeError(toJS(contextRef), "Objective-C blocks called as constructors must return an object."));
565: *exception = toRef(JSC::createTypeError(toJS(contextRef), "self type check failed for Objective-C instance method"));
575: *exception = toRef(JSC::createTypeError(toJS(contextRef), "self type check failed for Objective-C instance method"));
> My guess is that the ObjC API has to grab the APIEntryShim before it calls into JSC (via JSC::createTypeError).
Right.
Created attachment 224250 [details]
Patch
(In reply to comment #1) > There are a number of create calls throughout the ObjC API. They will all need to be audited: > > shell> ack 'create.*?Error' API/*.mm > API/JSValue.mm > 784: *exception = toRef(JSC::createTypeError(toJS(context), "Cannot convert primitive to NSArray")); > 800: *exception = toRef(JSC::createTypeError(toJS(context), "Cannot convert primitive to NSDictionary")); > > API/ObjCCallbackFunction.mm > 132: *exception = toRef(JSC::createTypeError(toJS(contextRef), "Argument does not match Objective-C Class")); > 456: // (2) We're calling some JSC internals that require us to be on the 'inside' - e.g. createTypeError. > 499: *exception = toRef(JSC::createTypeError(toJS(contextRef), "Objective-C blocks called as constructors must return an object.")); > 565: *exception = toRef(JSC::createTypeError(toJS(contextRef), "self type check failed for Objective-C instance method")); > 575: *exception = toRef(JSC::createTypeError(toJS(contextRef), "self type check failed for Objective-C instance method")); I audited the other call sites and other than these two they are all in places where we already hold the API lock. Comment on attachment 224250 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=224250&action=review r=me > Source/JavaScriptCore/API/JSValue.mm:785 > *exception = toRef(JSC::createTypeError(toJS(context), "Cannot convert primitive to NSArray")); Nit: You could ASCIILiteral(...) the string being passed to createTypeError, since it is a string literal turning into a WTF::String. Is the lock needed by the "tryUnwrapObjcObject" call at the top of these functions? Otherwise this is identical to the local fix I had. (In reply to comment #5) > (From update of attachment 224250 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=224250&action=review > > r=me > > > Source/JavaScriptCore/API/JSValue.mm:785 > > *exception = toRef(JSC::createTypeError(toJS(context), "Cannot convert primitive to NSArray")); > > Nit: You could ASCIILiteral(...) the string being passed to createTypeError, since it is a string literal turning into a WTF::String. > Will do. > Is the lock needed by the "tryUnwrapObjcObject" call at the top of these functions? > I don't think so. We don't create any objects in it, and the object is always reachable from the stack. If I missed something and we do need to take the shim for things that happen inside tryUnwrapObjcObject then the shim should probably go in there instead of out here. Committed r164136: <http://trac.webkit.org/changeset/164136> |