JavaScriptCore:
authorggaren <ggaren@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 12 Mar 2007 15:09:37 +0000 (15:09 +0000)
committerggaren <ggaren@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 12 Mar 2007 15:09:37 +0000 (15:09 +0000)
commitb6464c8b5e0aff5977ab93b89e5869044b00d624
tree2faceb128b81c000160292558ab3c7ec7e9125fa
parentc1fcfe8b75bc73ff3cf3ef06128a1eaec486877f
JavaScriptCore:

        Reviewed by Oliver Hunt.

        Fixed <rdar://problem/4681051> Installer crashes in KJS::Collector::
        markOtherThreadConservatively(KJS::Collector::Thread*) trying to install
        iLife 06 using Rosetta on an Intel Machine

        The problem was that our thread-specific data destructor would modify the
        list of active JavaScript threads without holding the JSLock, corrupting
        the list. Corruption was especially likely if one JavaScript thread exited
        while another was starting up.

        * JavaScriptCore.exp:
        * kjs/JSLock.cpp: Don't conflate locking the JSLock with registering a
        thread, since the thread-specific data destructor needs to lock
        without registering a thread. Instead, treat thread registration as a
        part of the convenience of the JSLock object, and whittle down JSLock::lock()
        to just the bits that actually do the locking.
        (KJS::JSLock::lock):
        (KJS::JSLock::registerThread):
        * kjs/JSLock.h: Updated comments to mention the new behavior above, and
        other recent changes.
        (KJS::JSLock::JSLock):
        * kjs/collector.cpp:
        (KJS::destroyRegisteredThread): Lock here.
        (KJS::Collector::registerThread): To match, assert that we're locked here.

JavaScriptGlue:

        Reviewed by Oliver Hunt.

        Updated in light of fix for <rdar://problem/4681051> Installer crashes
        in KJS::Collector::markOtherThreadConservatively(KJS::Collector::Thread*)
        trying to install iLife 06 using Rosetta on an Intel Machine

        * JavaScriptGlue.cpp:
        (JSLockInterpreter): Ensure backwards compatibility by calling
        registerThread() when explicitly taking the JSLock. (This doesn't happen
        automatically anymore.) I doubt this actally matters, but in JavaScriptGlue
        territory, that kind of thinking will get you killed.

WebKitTools:

        Reviewed by Oliver Hunt.

        Beefed up --threaded mode in light of <rdar://problem/4681051> Installer
        crashes in KJS::Collector::markOtherThreadConservatively(KJS::Collector::Thread*)
        trying to install iLife 06 using Rosetta on an Intel Machine

        --threaded mode now runs a bunch of different JavaScript threads, randomly
        killing and respawning them. This was sufficient for reproducing the
        bug on my MacBook Pro.

        * DumpRenderTree/DumpRenderTree.m:
        (javaScriptThreads):
        (runJavaScriptThread):
        (startJavaScriptThreads):
        (stopJavaScriptThreads):
        (dumpRenderTree):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@20115 268f45cc-cd09-0410-ab3c-d52691b4dbfc
JavaScriptCore/ChangeLog
JavaScriptCore/JavaScriptCore.exp
JavaScriptCore/kjs/JSLock.cpp
JavaScriptCore/kjs/JSLock.h
JavaScriptCore/kjs/collector.cpp
JavaScriptGlue/ChangeLog
JavaScriptGlue/JavaScriptGlue.cpp
WebKitTools/ChangeLog
WebKitTools/DumpRenderTree/DumpRenderTree.m