Windows has support for something called fibers, which are like lightweight versions of threads. Multiple fibers can run within the context of a single thread and they have access to the same thread local storage but have different stacks. If we create a new JSGlobalContext on one fiber, then switch to another fiber and create a JSGlobalContext there, we will call initializeThreading() once for each new JSGlobalContext created. However, since these fibers are technically running inside the same thread, they will clobber each other's wtfThreadData(), which is stored using thread local storage. This can lead to corruption of the WTFThreadData structure for the fibers other than the last one to create a new JSGlobalContext, including the StackBounds data structure which is used during conservative scanning, among other things. This can lead to crashes during garbage collection on Windows if fibers are used. A quick fix would be to always get a fresh StackBounds data structure when asking for it instead of using the cached version from the thread local storage. There is a larger problem in that these fibers can corrupt other WebKit data that uses thread local storage. We'll leave those theoretical fixes for future theoretical bugs.
Created attachment 174485 [details] Patch
Comment on attachment 174485 [details] Patch r=me This will fix cases that schedule one fiber at a time; we still don't support fiber A switching to fiber B recursively, since the stack will be discontiguous in that case.
Where are we using fibers???
(In reply to comment #3) > Where are we using fibers??? Clients of JSC on Windows could use fibers.
<rdar://problem/12679639>
Committed r134797: <http://trac.webkit.org/changeset/134797>