[Webkit-unassigned] [Bug 151165] jQuery 'is' implementation causes exception to be thrown

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=151165

--- Comment #3 from Chris Dumez <cdumez at apple.com> ---
(In reply to comment #0)
> Created attachment 265332 [details]
> Example that triggers the issue.
> 
> While debugging another issue, I noticed that exceptions were being thrown
> inside JSC in a fairly simple jQuery test page. These 'exceptions' are not
> catchable in script, and seem to be consumed inside WebKit without
> triggering any external exception handling behavior. Perhaps this is normal
> and expected, but I'm writing this bug up so we can make that decision.
> 
> Consider the following code:
> 
>     if (!elem.is(":visible")) {
>         ... do something
>     }
> 
> When this code is executed (at least in jQuery 2.1.4), we are encountering a
> DOMError 12 (Syntax Error) being generated in the
> WebCore::JsElementPrototypeFunctionMatches method.
> 
> +Â Â 377024 ( 408808 -Â Â 31784)Â Â Â Â 373 allocsBackTrace175CD6B0
> +Â Â Â Â Â 344 (Â Â Â Â 373 -Â Â Â Â Â 29)BackTrace175CD6B0allocations
> 
>     ntdll!RtlpCallInterceptRoutine+26
>     ntdll!RtlReAllocateHeap+3E7B1
>     WTF!realloc+43 (f:\dd\vctools\crt\crtw32\heap\realloc.c, 85)
>     WTF!WTF::fastRealloc+E (c:\bwa\wtf-7601.2.3\srcroot\wtf\fastmalloc.cpp,
> 155)
>     WTF!WTF::StringImpl::reallocateInternal<unsigned char>+72
> (c:\bwa\wtf-7601.2.3\srcroot\wtf\text\stringimpl.cpp, 224)
>     WTF!WTF::StringImpl::reallocate+23
> (c:\bwa\wtf-7601.2.3\srcroot\wtf\text\stringimpl.cpp, 231)
>     WTF!WTF::StringBuilder::reallocateBuffer<unsigned char>+4F
> (c:\bwa\wtf-7601.2.3\srcroot\wtf\text\stringbuilder.cpp, 150)
>     WTF!WTF::StringBuilder::appendUninitializedSlow<unsigned char>+3C
> (c:\bwa\wtf-7601.2.3\srcroot\wtf\text\stringbuilder.cpp, 235)
>     WTF!WTF::StringBuilder::append+73
> (c:\bwa\wtf-7601.2.3\srcroot\wtf\text\stringbuilder.cpp, 283)
>     JavaScriptCore!JSC::Interpreter::stackTraceAsString+C5
> (c:\bwa\javascriptcore-7601.2.3\srcroot\interpreter\interpreter.cpp, 580)
>     JavaScriptCore!JSC::addErrorInfoAndGetBytecodeOffset+2D2
> (c:\bwa\javascriptcore-7601.2.3\srcroot\runtime\error.cpp, 179)
>     JavaScriptCore!JSC::addErrorInfo+39
> (c:\bwa\javascriptcore-7601.2.3\srcroot\runtime\error.cpp, 190)
>     WebKit!WebCore::createDOMException+273
>     WebKit!WebCore::setDOMException+4B
>     WebKit!WebCore::jsElementPrototypeFunctionMatches+12A
> 
> The jsElementPrototypeFunctionMatches implementation calls the
> Element::matches method, which eventually takes us to
> SelectorQueryCache::add:
> 
>     SelectorQuery* SelectorQueryCache::add(const String& selectors,
> Document& document, ExceptionCode& ec)
>     SelectorQuery* Document::selectorQueryForString(const String&
> selectorString, ExceptionCode& ec)
>     bool Element::matches(const String& selector, ExceptionCode& ec)
> 
> When SelectorQueryCache::add parses the document looking for selectors, and
> does not find a match the exception code is set to 12 (SYNTAX_ERR) and it
> does an early return.
> 
> This returns a false value, and everyone is happy. Except, the presence of
> the SYNTAX_ERR code causes us to generate an exception objects:
> 
>     JSValue result = jsBoolean(impl.matches(selectors, ec));
> 
>     setDOMException(state, ec);
>     return JSValue::encode(result);
> 
> The call to 'setDOMException' creates an exception object, which lives in
> the JSC heap until it gets cleaned up. The exception object is fairly
> heavy-weight, since it contains a call stack and other information about the
> error location. In some jQuery applications we measured, this can produce a
> few Megabytes of memory use within a short period.
> 
> I'm wondering if we really do want to be treating this 'normal' matches case
> as an exception.

If we throw, this likely means that we were unable to parse this selector. Throwing in such case is as per the spec. However, I am not familiar enough with this selector to know if it is valid.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151112/a772c8d3/attachment-0001.html>