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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Nov 11 16:25:57 PST 2015


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

            Bug ID: 151165
           Summary: jQuery 'is' implementation causes exception to be
                    thrown
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: bfulgham at webkit.org

Created attachment 265332
  --> https://bugs.webkit.org/attachment.cgi?id=265332&action=review
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.

-- 
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/fb9b61a1/attachment.html>


More information about the webkit-unassigned mailing list