Ignore:
Timestamp:
Mar 12, 2007, 8:09:37 AM (18 years ago)
Author:
ggaren
Message:

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):
File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/JavaScriptCore/kjs/collector.cpp

    r20019 r20115  
    237237  Collector::Thread *thread = (Collector::Thread *)data;
    238238
     239  // Can't use JSLock convenience object here because we don't want to re-register
     240  // an exiting thread.
     241  JSLock::lock();
     242 
    239243  if (registeredThreads == thread) {
    240244    registeredThreads = registeredThreads->next;
    241245  } else {
    242246    Collector::Thread *last = registeredThreads;
    243     for (Collector::Thread *t = registeredThreads->next; t != NULL; t = t->next) {
     247    Collector::Thread *t;
     248    for (t = registeredThreads->next; t != NULL; t = t->next) {
    244249      if (t == thread) {
    245250        last->next = t->next;
     
    248253      last = t;
    249254    }
    250   }
     255    ASSERT(t); // If t is NULL, we never found ourselves in the list.
     256  }
     257
     258  JSLock::unlock();
    251259
    252260  delete thread;
     
    260268void Collector::registerThread()
    261269{
     270  ASSERT(JSLock::lockCount() > 0);
     271 
    262272  pthread_once(&registeredThreadKeyOnce, initializeRegisteredThreadKey);
    263273
Note: See TracChangeset for help on using the changeset viewer.