Bug 130122 – W32: Use-after-free in WTF threading code

• Status: NEW
• Component: Web Template Framework

[LRN]

From ThreadingWin.cpp:

static unsigned __stdcall wtfThreadEntryPoint(void* param)
{
    OwnPtr<ThreadFunctionInvocation> invocation = adoptPtr(static_cast<ThreadFunctionInvocation*>(param));
    invocation->function(invocation->data);

#if !USE(PTHREADS) && OS(WINDOWS)
    // Do the TLS cleanup.
    ThreadSpecificThreadExit();
#endif

    return 0;
}

This code causes a crash.

Here's my understanding of the problem:

The "invocation" object is created at the beginning of the function, and then used in the next line.

After that, ThreadSpecificThreadExit() is called. ThreadSpecificThreadExit() does some cleanup, including freeing the thread heap (or somesuch). The important thing is that it marks the memory occupied by "invocation" as "free", and puts 0x0 pointer into the memory it occupied.

Then the function returns, "invocation" goes out of scope, and its destructor is called. Destructor alters the memory - which, incidentally, alters its contents, and hits exactly the same spot where SLL was storing its data during ThreadSpecificThreadExit(), changing 0x0 to some other value (usually 0x8 or 0xf8, it changes between runs).

Later on WTF::PageHeapAllocator<WTF::TCMalloc_ThreadCache>::New() calls SLL_Next, which gets the (altered) value that was previously stored in the free memory region, and returns it as the new list head.

Later on WTF::PageHeapAllocator<WTF::TCMalloc_ThreadCache>::New() is called again, and this time list head pointer is 0x8. SLL_Next() tries to dereference it and crashes.

[LRN]

Created attachment 226489 [details]
Make sure invocation is destroyed before running thread cleanup

Adding extra scope to make sure that invocation object is killed before running thread cleanup routine.

[WebKit Commit Bot]

Attachment 226489 [details] did not pass style-queue:


Total errors found: 0 in 0 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Alexey Proskuryakov]

I'm not convinced about the root cause. There is no way ThreadSpecificThreadExit() could possibly change the value of invocation - it's an object allocated on the stack. It also cannot touch ThreadFunctionInvocation - first, it doesn't delete heap objects, and second, this particular object was created on a different thread in the first place.

Perhaps FastMalloc becomes entirely unusable after ThreadSpecificThreadExit()? That seems possible, and if so, the fix would address the crash. It may be that a better fix would be inside FastMalloc code.

Could you please post steps to reproduce this crash?

See also: bug 44137.

[Brent Fulgham]

It looks like this was encountered on a Gtk+-in-Windows environment. I wonder if there's something different about the threading models in that context? Doesn't the Gtk build (even on Windows) use pthreads?

[LRN]

(In reply to comment #3)
> I'm not convinced about the root cause. There is no way ThreadSpecificThreadExit() could possibly change the value of invocation - it's an object allocated on the stack. It also cannot touch ThreadFunctionInvocation - first, it doesn't delete heap objects, and second, this particular object was created on a different thread in the first place.

Invocation object is allocated on stack, but it seems to allocate something on the heap too (either invocation constructor, or adoptPtr() or something else in that line - i have no way to debug this, because C++).

> 
> Perhaps FastMalloc becomes entirely unusable after ThreadSpecificThreadExit()? That seems possible, and if so, the fix would address the crash. It may be that a better fix would be inside FastMalloc code.

Possible.


> 
> Could you please post steps to reproduce this crash?

Build webkitgtk, run "GtkLauncher.exe http://google.com"

> 
> See also: bug 44137.

Can't tell whether it's related or not.

(In reply to comment #4)
> It looks like this was encountered on a Gtk+-in-Windows environment.

Correct.

> I wonder if there's something different about the threading models in that context? Doesn't the Gtk build (even on Windows) use pthreads?

GTK+ itself doesn't have threads, glib does. Glib can be built with W32 threads or with POSIX threads.
I'm not sure whether this affects WebKit, since it seems to be using its own threading code.

[LRN]

Here's what is happening with free_list_:

Hardware watchpoint 2: WTF::threadheap_allocator.free_list_

Old value = {m_value = 0x0}
New value = {m_value = 0x7ef306a0}
WTF::PageHeapAllocator<WTF::TCMalloc_ThreadCache>::Delete (this=0xcc7978 <WTF::threadheap_allocator>, p=0x7ef306a0) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:1134
1134        inuse_--;
(gdb) l
1129
1130      void Delete(T* p) {
1131        HardenedSLL new_head = HardenedSLL::create(p);
1132        SLL_SetNext(new_head, free_list_, entropy_);
1133        free_list_ = new_head;
1134        inuse_--;
1135      }
1136
1137      int inuse() const { return inuse_; }
1138
(gdb) bt
#0  WTF::PageHeapAllocator<WTF::TCMalloc_ThreadCache>::Delete (this=0xcc7978 <WTF::threadheap_allocator>, p=0x7ef306a0) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:1134
#1  0x00a41aaa in WTF::TCMalloc_ThreadCache::DeleteCache (heap=0x7ef306a0) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:3649
#2  0x00a41a01 in WTF::TCMalloc_ThreadCache::DestroyThreadCache (ptr=0x7ef306a0) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:3634
#3  0x00b8be39 in WTF::PlatformThreadSpecificKey::callDestructor (this=0x199df008) at ../webkitgtk-2.2.6/Source/WTF/wtf/ThreadSpecificWin.cpp:70
#4  0x00a47d2c in WTF::ThreadSpecificThreadExit () at ../webkitgtk-2.2.6/Source/WTF/wtf/ThreadSpecificWin.cpp:133
#5  0x00a480d1 in WTF::wtfThreadEntryPoint (param=0x7ee3e0f0) at ../webkitgtk-2.2.6/Source/WTF/wtf/ThreadingWin.cpp:222
#6  0x774e1287 in msvcrt!_itow_s () from C:\Windows\syswow64\msvcrt.dll
#7  0x774e1328 in msvcrt!_endthreadex () from C:\Windows\syswow64\msvcrt.dll
#8  0x7598338a in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
#9  0x77b89f72 in ntdll!RtlInitializeExceptionChain () from C:\Windows\system32\ntdll.dll
#10 0x77b89f45 in ntdll!RtlInitializeExceptionChain () from C:\Windows\system32\ntdll.dll
#11 0x00000000 in ?? ()

Then, at some later point, this happens:

(gdb) bt
#0  WTF::SLL_Next (t=..., entropy=2604373617) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:832
#1  0x00b7f7fc in WTF::PageHeapAllocator<WTF::TCMalloc_ThreadCache>::New (this=0xcc7978 <WTF::threadheap_allocator>) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:1108
#2  0x00b8451c in WTF::TCMalloc_ThreadCache::NewHeap (tid=8280, entropy=2604373617) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:3476
#3  0x00a4193f in WTF::TCMalloc_ThreadCache::CreateCacheIfNecessary () at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:3588
#4  0x00b84719 in WTF::TCMalloc_ThreadCache::GetCache () at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:3506
#5  0x00a42180 in WTF::do_malloc<true> (size=55) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:4041
#6  0x00b5a0bd in WTF::fastMalloc<true> (size=55) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:4281
#7  0x00a41e66 in WTF::fastMalloc (size=55) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:4244
#8  0x00a52ea4 in WTF::CStringBuffer::createUninitialized (length=46) at ../webkitgtk-2.2.6/Source/WTF/wtf/text/CString.cpp:42
#9  0x00a52f83 in WTF::CString::init (this=0x1a4efe8c, str=0x1a4ef9f4 "C:\\Users\\LRN\\AppData\\Local\\webkit\\icondatabase?u", length=46) at ../webkitgtk-2.2.6/Source/WTF/wtf/text/CString.cpp:68
#10 0x00a52f60 in WTF::CString::CString (this=0x1a4efe8c, str=0x1a4ef9f4 "C:\\Users\\LRN\\AppData\\Local\\webkit\\icondatabase?u", length=46) at ../webkitgtk-2.2.6/Source/WTF/wtf/text/CString.cpp:61
#11 0x00a59397 in WTF::StringImpl::utf8ForRange (this=0x7ee3f2d0, offset=0, length=46, mode=WTF::LenientConversion) at ../webkitgtk-2.2.6/Source/WTF/wtf/text/StringImpl.cpp:2069
#12 0x00a593e8 in WTF::StringImpl::utf8 (this=0x7ee3f2d0, mode=WTF::LenientConversion) at ../webkitgtk-2.2.6/Source/WTF/wtf/text/StringImpl.cpp:2074
#13 0x00a5c3f3 in WTF::String::utf8 (this=0x7ee3dc18, mode=WTF::LenientConversion) at ../webkitgtk-2.2.6/Source/WTF/wtf/text/WTFString.cpp:800
#14 0x68cd3a0c in fileSystemRepresentation () at ../webkitgtk-2.2.6/Source/WebCore/platform/gtk/FileSystemGtk.cpp:59
#15 makeAllDirectories () at ../webkitgtk-2.2.6/Source/WebCore/platform/gtk/FileSystemGtk.cpp:173
#16 0x6913db9e in iconDatabaseSyncThread () at ../webkitgtk-2.2.6/Source/WebCore/loader/icon/IconDatabase.cpp:996
#17 0x00a47db1 in WTF::threadEntryPoint (contextData=0x7ee412a8) at ../webkitgtk-2.2.6/Source/WTF/wtf/Threading.cpp:69
#18 0x00a480cc in WTF::wtfThreadEntryPoint (param=0x7ee3e6c8) at ../webkitgtk-2.2.6/Source/WTF/wtf/ThreadingWin.cpp:218
#19 0x774e1287 in msvcrt!_itow_s () from C:\Windows\syswow64\msvcrt.dll
#20 0x774e1328 in msvcrt!_endthreadex () from C:\Windows\syswow64\msvcrt.dll
#21 0x7598338a in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
#22 0x77b89f72 in ntdll!RtlInitializeExceptionChain () from C:\Windows\system32\ntdll.dll
#23 0x77b89f45 in ntdll!RtlInitializeExceptionChain () from C:\Windows\system32\ntdll.dll
#24 0x00000000 in ?? ()
(gdb) p t
$74 = {m_value = 0x7ef306a0}
(gdb) s
WTF::HardenedSLL::value (this=0x1a4ef7c0) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:788
788         ALWAYS_INLINE void* value() const { return m_value; }
(gdb) s
WTF::SLL_Next (t=..., entropy=2604373617) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:833
833         return HardenedSLL::create(XOR_MASK_PTR_WITH_KEY(tValueNext, t.value(), entropy));
(gdb) s
WTF::HardenedSLL::value (this=0x1a4ef7c0) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:788
788         ALWAYS_INLINE void* value() const { return m_value; }
(gdb) s
WTF::HardenedSLL::value (this=0x1a4ef7c0) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:788
788         ALWAYS_INLINE void* value() const { return m_value; }
(gdb) s
WTF::HardenedSLL::create (value=0x18) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:776
776             result.m_value = value;
(gdb) p result
$75 = {m_value = 0x1a4ef7c0}
(gdb) n
777             return result;
(gdb) p result
$76 = {m_value = 0x18}

which leads to

Hardware watchpoint 2: WTF::threadheap_allocator.free_list_

Old value = {m_value = 0x7ef306a0}
New value = {m_value = 0x18}
0x00b7f7ff in WTF::PageHeapAllocator<WTF::TCMalloc_ThreadCache>::New (this=0xcc7978 <WTF::threadheap_allocator>) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:1108
1108          free_list_ = SLL_Next(free_list_, entropy_);


And then this

(gdb) bt
#0  WTF::SLL_Next (t=..., entropy=2604373617) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:832
#1  0x00b7f7fc in WTF::PageHeapAllocator<WTF::TCMalloc_ThreadCache>::New (this=0xcc7978 <WTF::threadheap_allocator>) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:1108
#2  0x00b8451c in WTF::TCMalloc_ThreadCache::NewHeap (tid=5288, entropy=2604373617) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:3476
#3  0x00a4193f in WTF::TCMalloc_ThreadCache::CreateCacheIfNecessary () at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:3588
#4  0x00b84719 in WTF::TCMalloc_ThreadCache::GetCache () at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:3506
#5  0x00a42180 in WTF::do_malloc<true> (size=1) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:4041
#6  0x00b5a0bd in WTF::fastMalloc<true> (size=1) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:4281
#7  0x00a41e66 in WTF::fastMalloc (size=1) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:4244
#8  0x00a3f7d6 in WTF::fastZeroedMalloc (n=1) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:212
#9  0x00b6e1ec in WTF::ThreadSpecific<bool>::operator bool* (this=0x199df260) at ../webkitgtk-2.2.6/Source/WTF/wtf/ThreadSpecific.h:261
#10 0x00b6e237 in WTF::ThreadSpecific<bool>::operator* (this=0x199df260) at ../webkitgtk-2.2.6/Source/WTF/wtf/ThreadSpecific.h:277
#11 0x00a43afa in WTF::registerGCThread () at ../webkitgtk-2.2.6/Source/WTF/wtf/MainThread.cpp:273
#12 0x0099eff4 in JSC::GCThread::gcThreadMain (this=0x1ac30168) at ../webkitgtk-2.2.6/Source/JavaScriptCore/heap/GCThread.cpp:90
#13 0x0099f0ee in JSC::GCThread::gcThreadStartFunc (data=0x1ac30168) at ../webkitgtk-2.2.6/Source/JavaScriptCore/heap/GCThread.cpp:135
#14 0x00a47db1 in WTF::threadEntryPoint (contextData=0x7ee41e10) at ../webkitgtk-2.2.6/Source/WTF/wtf/Threading.cpp:69
#15 0x00a480cc in WTF::wtfThreadEntryPoint (param=0x7ee3e6b8) at ../webkitgtk-2.2.6/Source/WTF/wtf/ThreadingWin.cpp:218
#16 0x774e1287 in msvcrt!_itow_s () from C:\Windows\syswow64\msvcrt.dll
#17 0x774e1328 in msvcrt!_endthreadex () from C:\Windows\syswow64\msvcrt.dll
#18 0x7598338a in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
#19 0x77b89f72 in ntdll!RtlInitializeExceptionChain () from C:\Windows\system32\ntdll.dll
#20 0x77b89f45 in ntdll!RtlInitializeExceptionChain () from C:\Windows\system32\ntdll.dll
#21 0x00000000 in ?? ()

crashes when it tries to dereference 0x18

[LRN]

Without hardening it's easier to see:

Breakpoint 2, WTF::PageHeapAllocator<WTF::TCMalloc_ThreadCache>::Delete (this=0x8c4978 <WTF::threadheap_allocator>, p=0x7ef306a0) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:1131
1131        HardenedSLL new_head = HardenedSLL::create(p);
(gdb) n
[New Thread 4012.0x1e58]
1132        SLL_SetNext(new_head, free_list_, entropy_);
(gdb)
1133        free_list_ = new_head;
(gdb)
Hardware watchpoint 1: WTF::threadheap_allocator.free_list_

Old value = {m_value = 0x0}
New value = {m_value = 0x7ef306a0}
WTF::PageHeapAllocator<WTF::TCMalloc_ThreadCache>::Delete (this=0x8c4978 <WTF::threadheap_allocator>, p=0x7ef306a0) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:1134
1134        inuse_--;
(gdb) bt
#0  WTF::PageHeapAllocator<WTF::TCMalloc_ThreadCache>::Delete (this=0x8c4978 <WTF::threadheap_allocator>, p=0x7ef306a0) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:1134
#1  0x0064197e in WTF::TCMalloc_ThreadCache::DeleteCache (heap=0x7ef306a0) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:3649
#2  0x006418d5 in WTF::TCMalloc_ThreadCache::DestroyThreadCache (ptr=0x7ef306a0) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:3634
#3  0x0078c001 in WTF::PlatformThreadSpecificKey::callDestructor (this=0x2c76f008) at ../webkitgtk-2.2.6/Source/WTF/wtf/ThreadSpecificWin.cpp:70
#4  0x00647ae8 in WTF::ThreadSpecificThreadExit () at ../webkitgtk-2.2.6/Source/WTF/wtf/ThreadSpecificWin.cpp:133
#5  0x00647e8d in WTF::wtfThreadEntryPoint (param=0x7ee3e0f0) at ../webkitgtk-2.2.6/Source/WTF/wtf/ThreadingWin.cpp:222
#6  0x774e1287 in msvcrt!_itow_s () from C:\Windows\syswow64\msvcrt.dll
#7  0x774e1328 in msvcrt!_endthreadex () from C:\Windows\syswow64\msvcrt.dll
#8  0x7598338a in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
#9  0x77b89f72 in ntdll!RtlInitializeExceptionChain () from C:\Windows\system32\ntdll.dll
#10 0x77b89f45 in ntdll!RtlInitializeExceptionChain () from C:\Windows\system32\ntdll.dll
#11 0x00000000 in ?? ()
(gdb) p *(void**)0x7ef306a0
$46 = (void *) 0x0
(gdb) watch *(void**)0x7ef306a0
Hardware watchpoint 6: *(void**)0x7ef306a0
(gdb) c
Continuing.
Hardware watchpoint 6: *(void**)0x7ef306a0

Old value = (void *) 0x0
New value = (void *) 0x8
WTF::TCMalloc_ThreadCache::Deallocate (this=0x7ef306a0, ptr=..., cl=1) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:3328
3328      FreeList* list = &list_[cl];
(gdb) bt
#0  WTF::TCMalloc_ThreadCache::Deallocate (this=0x7ef306a0, ptr=..., cl=1) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:3328
#1  0x00641b34 in WTF::do_free (ptr=0x7ee3e0f0) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:4091
#2  0x00641c6e in WTF::fastFree (ptr=0x7ee3e0f0) at ../webkitgtk-2.2.6/Source/WTF/wtf/FastMalloc.cpp:4307
#3  0x0078be84 in WTF::ThreadFunctionInvocation::operator delete (p=0x7ee3e0f0) at ../webkitgtk-2.2.6/Source/WTF/wtf/ThreadFunctionInvocation.h:37
#4  0x00770359 in WTF::deleteOwnedPtr<WTF::ThreadFunctionInvocation> (ptr=0x7ee3e0f0) at ../webkitgtk-2.2.6/Source/WTF/wtf/OwnPtrCommon.h:63
#5  0x00792372 in WTF::OwnPtr<WTF::ThreadFunctionInvocation>::~OwnPtr (this=0x2f09ff34, __in_chrg=<optimized out>) at ../webkitgtk-2.2.6/Source/WTF/wtf/OwnPtr.h:63
#6  0x00647e9c in WTF::wtfThreadEntryPoint (param=0x7ee3e0f0) at ../webkitgtk-2.2.6/Source/WTF/wtf/ThreadingWin.cpp:224
#7  0x774e1287 in msvcrt!_itow_s () from C:\Windows\syswow64\msvcrt.dll
#8  0x774e1328 in msvcrt!_endthreadex () from C:\Windows\syswow64\msvcrt.dll
#9  0x7598338a in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
#10 0x77b89f72 in ntdll!RtlInitializeExceptionChain () from C:\Windows\system32\ntdll.dll
#11 0x77b89f45 in ntdll!RtlInitializeExceptionChain () from C:\Windows\system32\ntdll.dll
#12 0x00000000 in ?? ()
(gdb) l
3323    }
3324
3325    inline void TCMalloc_ThreadCache::Deallocate(HardenedSLL ptr, size_t cl) {
3326      size_t allocationSize = ByteSizeForClass(cl);
3327      size_ += allocationSize;
3328      FreeList* list = &list_[cl];
3329      if (MAY_BE_POISONED(ptr.value(), allocationSize))
3330          list->Validate(ptr, allocationSize);
3331
3332      POISON_DEALLOCATION(ptr.value(), allocationSize);
(gdb) p list_
$47 = {{list_ = {m_value = 0x0}, length_ = 0, lowater_ = 0, entropy_ = 0} <repeats 68 times>}
(gdb) p cl
$48 = 1
(gdb) p list_[cl]
$49 = {list_ = {m_value = 0x0}, length_ = 0, lowater_ = 0, entropy_ = 0}
(gdb) p size_
$50 = 8
(gdb) p this
$51 = (WTF::TCMalloc_ThreadCache * const) 0x7ef306a0
(gdb) p *this
$52 = {size_ = 8, tid_ = 5916, in_setspecific_ = true, list_ = {{list_ = {m_value = 0x0}, length_ = 0, lowater_ = 0, entropy_ = 0} <repeats 68 times>}, rnd_ = 2242692540, bytes_until_sample_ = 1556019, entropy_ = 0, next_ = 0x7ef30350, prev_ = 0x0}

[Carlos Garcia Campos]

Comment on attachment 226489 [details]
Make sure invocation is destroyed before running thread cleanup

Could you provide a ChangeLog entry?

[LRN]

How should the changelog entry look like? AFAICS, there's no ChangeLog in WTF subdir. Should it go into toplevel ChangeLog?

[Michael Catanzaro]

The file you want to edit is Source/WTF/ChangeLog.  You can use Tools/Scripts/prepare-ChangeLog to fill in the template. Thanks. :)

Also, I think you should add a comment above your changes, because otherwise someone might come along and remove those braces down the road.

[LRN]

While preparing a patch for submission, i've decided to see if this bug affects 2.4.8, which i was able to build recently.

It doesn't. It affects neither my build (i686), nor alexey's builds (x86_64 and i686).

I don't know why.

Since versions prior to 2.4.x are not supported anymore, i guess this bugreport is now obsolete.

[Alex Christensen]

There are still Windows ports of WebKit that use this code, right?  Is this a problem that could still be hit?  If so, we should fix it.

[LRN]

Created attachment 250522 [details]
Fix a crash in Windows WTF threading

In case it's useful, here's a fresh patch against git wekbit-2.4 head. With changelog entry and code comment. The wording of both indicates that this problem still exists; i can't vouch that this is true, and i don't feel like debugging the guts of heap allocation again to see why this problem does not occur anymore (which doubles the difficulty, as i can't wait for a crash and get a backtrace).