130122 2014-03-12 03:29:37 -0700 W32: Use-after-free in WTF threading code 2015-04-10 10:30:52 -0700 1 1 1 Unclassified WebKit Web Template Framework 528+ (Nightly build) All Windows 7 NEW P2 Critical --- 1 lrn1986 webkit-unassigned achristensen ap bfulgham cgarcia commit-queue ggaren mcatanzaro roger_fong oldest_to_newest 989574 0 lrn1986 2014-03-12 03:29:37 -0700 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. 989575 1 226489 lrn1986 2014-03-12 03:31:38 -0700 Created attachment 226489 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. 999816 2 commit-queue 2014-04-11 00:30:31 -0700 Attachment 226489 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. 999925 3 ap 2014-04-11 10:42:12 -0700 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. 999934 4 bfulgham 2014-04-11 10:56:53 -0700 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? 999988 5 lrn1986 2014-04-11 12:54:03 -0700 (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. 1007618 6 lrn1986 2014-05-08 08:20:00 -0700 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 1007651 7 lrn1986 2014-05-08 09:46:39 -0700 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} 1083313 8 226489 cgarcia 2015-04-07 08:54:07 -0700 Comment on attachment 226489 Make sure invocation is destroyed before running thread cleanup Could you provide a ChangeLog entry? 1083370 9 lrn1986 2015-04-07 11:40:18 -0700 How should the changelog entry look like? AFAICS, there's no ChangeLog in WTF subdir. Should it go into toplevel ChangeLog? 1083382 10 mcatanzaro 2015-04-07 12:29:30 -0700 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. 1084259 11 lrn1986 2015-04-10 02:59:49 -0700 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. 1084327 12 achristensen 2015-04-10 10:19:12 -0700 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. 1084331 13 250522 lrn1986 2015-04-10 10:30:52 -0700 Created attachment 250522 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). 226489 2014-03-12 03:31:38 -0700 2015-04-10 10:30:52 -0700 Make sure invocation is destroyed before running thread cleanup 0027-destroy-invocation-before-return.all.patch text/plain 656 lrn1986 LS0tIHdlYmtpdGd0ay0yLjIuNS9Tb3VyY2UvV1RGL3d0Zi9UaHJlYWRpbmdXaW4uY3BwLm9yaWcJ MjAxNC0wMi0xNyAxMToyNDowMy4wMDAwMDAwMDAgKzAwMDAKKysrIHdlYmtpdGd0ay0yLjIuNS9T b3VyY2UvV1RGL3d0Zi9UaHJlYWRpbmdXaW4uY3BwCTIwMTQtMDMtMTIgMDc6MjE6NDYuMTQ0ODQy MjAwICswMDAwCkBAIC0yMTIsOCArMjEyLDEwIEBACiAKIHN0YXRpYyB1bnNpZ25lZCBfX3N0ZGNh bGwgd3RmVGhyZWFkRW50cnlQb2ludCh2b2lkKiBwYXJhbSkKIHsKLSAgICBPd25QdHI8VGhyZWFk RnVuY3Rpb25JbnZvY2F0aW9uPiBpbnZvY2F0aW9uID0gYWRvcHRQdHIoc3RhdGljX2Nhc3Q8VGhy ZWFkRnVuY3Rpb25JbnZvY2F0aW9uKj4ocGFyYW0pKTsKLSAgICBpbnZvY2F0aW9uLT5mdW5jdGlv bihpbnZvY2F0aW9uLT5kYXRhKTsKKyAgICB7CisgICAgICBPd25QdHI8VGhyZWFkRnVuY3Rpb25J bnZvY2F0aW9uPiBpbnZvY2F0aW9uID0gYWRvcHRQdHIoc3RhdGljX2Nhc3Q8VGhyZWFkRnVuY3Rp b25JbnZvY2F0aW9uKj4ocGFyYW0pKTsKKyAgICAgIGludm9jYXRpb24tPmZ1bmN0aW9uKGludm9j YXRpb24tPmRhdGEpOworICAgIH0KIAogI2lmICFVU0UoUFRIUkVBRFMpICYmIE9TKFdJTkRPV1Mp CiAgICAgLy8gRG8gdGhlIFRMUyBjbGVhbnVwLgo= 250522 2015-04-10 10:30:52 -0700 2015-04-10 10:30:52 -0700 Fix a crash in Windows WTF threading 0001-Fix-a-crash-in-Windows-WTF-threading.patch text/plain 1981 lrn1986 RnJvbSBmYTU1NTJmYWNlMzFhNDJiMWE4MzE1OTc2MTY0NGNjNDY2NmZjZDI3IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/PUQwPUEwPUQxPTgzPUQxPTgxPUQwPUJCPUQw PUIwPUQwPUJEPTIwPUQwPTk4PUQwPUI2PUQwPUIxPz0KID0/VVRGLTg/cT89RDE9ODM9RDA9QkI9 RDA9QjA9RDE9ODI9RDA9QkU9RDA9QjI/PSA8bHJuMTk4NkBnbWFpbC5jb20+CkRhdGU6IEZyaSwg MTAgQXByIDIwMTUgMTc6MjM6MTYgKzAwMDAKU3ViamVjdDogW1BBVENIXSBGaXggYSBjcmFzaCBp biBXaW5kb3dzIFdURiB0aHJlYWRpbmcKCi0tLQogU291cmNlL1dURi9DaGFuZ2VMb2cgICAgICAg ICAgICB8ICA5ICsrKysrKysrKwogU291cmNlL1dURi93dGYvVGhyZWFkaW5nV2luLmNwcCB8IDEw ICsrKysrKystLS0KIDIgZmlsZXMgY2hhbmdlZCwgMTYgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlv bnMoLSkKCmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL0NoYW5nZUxvZyBiL1NvdXJjZS9XVEYvQ2hh bmdlTG9nCmluZGV4IDhmMDNhNTguLjRmYzk2Y2UgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvQ2hh bmdlTG9nCisrKyBiL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTIgQEAKKzIwMTUt MDQtMTAgINCg0YPRgdC70LDQvSDQmNC20LHRg9C70LDRgtC+0LIgIDxscm4xOTg2QGdtYWlsLmNv bT4KKworICAgICAgICBGaXggYSBjcmFzaCBpbiBXaW5kb3dzIFdURiB0aHJlYWRpbmcKKyAgICAg ICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTEzMDEyMgorCisgICAg ICAgIFJldmlld2VkIGJ5ICBDYXJsb3MgR2FyY2lhIENhbXBvcy4KKworICAgICAgICAqIHd0Zi9U aHJlYWRpbmdXaW4uY3BwOiBhZGQgc2NvcGUgdG8gZW5zdXJlIGVhcmx5IGRlc3RydWN0aW9uCisK IDIwMTUtMDEtMjAgIFl1blFpYW5nIFN1ICA8d3pzc3lxYUBnbWFpbC5jb20+CiAKICAgICAgICAg Rml4IGZhaWxlZCB0byBidWlsZCBmb3IgTGludXgvTUlQUzY0RUwKZGlmZiAtLWdpdCBhL1NvdXJj ZS9XVEYvd3RmL1RocmVhZGluZ1dpbi5jcHAgYi9Tb3VyY2UvV1RGL3d0Zi9UaHJlYWRpbmdXaW4u Y3BwCmluZGV4IGUzN2M3N2UuLjhiN2Q4YjMgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvd3RmL1Ro cmVhZGluZ1dpbi5jcHAKKysrIGIvU291cmNlL1dURi93dGYvVGhyZWFkaW5nV2luLmNwcApAQCAt MjAyLDkgKzIwMiwxMyBAQCBzdGF0aWMgdm9pZCBjbGVhclRocmVhZEhhbmRsZUZvcklkZW50aWZp ZXIoVGhyZWFkSWRlbnRpZmllciBpZCkKIAogc3RhdGljIHVuc2lnbmVkIF9fc3RkY2FsbCB3dGZU aHJlYWRFbnRyeVBvaW50KHZvaWQqIHBhcmFtKQogewotICAgIE93blB0cjxUaHJlYWRGdW5jdGlv bkludm9jYXRpb24+IGludm9jYXRpb24gPSBhZG9wdFB0cihzdGF0aWNfY2FzdDxUaHJlYWRGdW5j dGlvbkludm9jYXRpb24qPihwYXJhbSkpOwotICAgIGludm9jYXRpb24tPmZ1bmN0aW9uKGludm9j YXRpb24tPmRhdGEpOwotCisgICAgLy8gVGhpcyBleHRyYSBzY29wZSBpcyBoZXJlIHRvIGVuc3Vy ZSB0aGF0IGludm9jYXRpb24gb2JqZWN0CisgICAgLy8gZ2V0cyBkZXN0cm95ZWQgKmJlZm9yZSog VGhyZWFkU3BlY2lmaWNUaHJlYWRFeGl0ICgpLAorICAgIC8vIGFzIGl0IGRlc3Ryb3lzIHRoZSB0 aHJlYWQgaGVhcCB0aGF0IGludm9jYXRpb24gaW5kaXJlY3RseSB1c2VzLgorICAgIHsKKyAgICAg ICAgT3duUHRyPFRocmVhZEZ1bmN0aW9uSW52b2NhdGlvbj4gaW52b2NhdGlvbiA9IGFkb3B0UHRy KHN0YXRpY19jYXN0PFRocmVhZEZ1bmN0aW9uSW52b2NhdGlvbio+KHBhcmFtKSk7CisgICAgICAg IGludm9jYXRpb24tPmZ1bmN0aW9uKGludm9jYXRpb24tPmRhdGEpOworICAgIH0KICNpZiAhVVNF KFBUSFJFQURTKSAmJiBPUyhXSU5ET1dTKQogICAgIC8vIERvIHRoZSBUTFMgY2xlYW51cC4KICAg ICBUaHJlYWRTcGVjaWZpY1RocmVhZEV4aXQoKTsKLS0gCjEuOC41LjMKCg==