[Webkit-unassigned] [Bug 158290] New: Runaway WebContent process CPU & memory @ foxnews.com

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jun 1 17:58:22 PDT 2016


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

            Bug ID: 158290
           Summary: Runaway WebContent process CPU & memory @ foxnews.com
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: msaboff at apple.com

Some foxnews.com pages with embedded videos have this code:

start : function() {
    if (this.started === true) {
        return;
    }
    try {
        this.plugin.Media.open(this.getMediaName(), this.media.getDuration(), this.getPlayerName()); // <== Exception here
        this.started = true;
    } catch (error) {
        this.error(error);
    }
    this.play(); // recursively call play()
}

play : function() {
    if (this.started !== true) {
        this.start(); // <== call here
        return;
    }
    try {
        this.plugin.Media.play(this.getMediaName(), this.getPlaybackCore().getCurrentTime() || 0);
    } catch (error) {
        this.error(error);
    }
}

This can end up being a mutual recursive call chain that will eventually exceed the stack space.  This happens when this.plugin.Media.open() in start() throws an exception.  That exception is caught in the catch block, but start() then calls play().  At the top of play(), it will recursively call start() and we end up in a recursive loop.  While the stack grows, the amount of memory used goes up dramatically.  The memory use is due to the error objects that are created for each throw.  The catch will be handled in baseline JIT'ed code as the higher tiers will ORS exit at the start of their catch blocks.  The baseline JIT'ed code will allocate a local for the thrown value and the conservative scan of the stack during GC will include the thrown value.  This means that the error objects for all start() frames further up the stack will not be collected.

-- 
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/20160602/34b565aa/attachment.html>


More information about the webkit-unassigned mailing list