TransactionOperations can get destroyed on the wrong thread

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Brady Eidson]

TransactionOperations can get destroyed on the wrong thread

This can happen for worker transaction operations.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.JavaScriptCore      	0x0000000105cda037 WTFCrash + 39
1   com.apple.WebCore             	0x000000010ba8dde8 WebCore::IDBClient::TransactionOperation::~TransactionOperation() + 104
2   com.apple.WebCore             	0x000000010baa8ea5 WebCore::IDBClient::TransactionOperationImpl<WebCore::IDBKeyData const&, unsigned long const&>::~TransactionOperationImpl() + 21
3   com.apple.WebCore             	0x000000010baa55c5 WebCore::IDBClient::TransactionOperationImpl<WebCore::IDBKeyData const&, unsigned long const&>::~TransactionOperationImpl() + 21
4   com.apple.WebCore             	0x000000010baa55e9 WebCore::IDBClient::TransactionOperationImpl<WebCore::IDBKeyData const&, unsigned long const&>::~TransactionOperationImpl() + 25
5   com.apple.WebCore             	0x000000010ba02cd3 WTF::ThreadSafeRefCounted<WebCore::IDBClient::TransactionOperation>::deref() + 83
6   com.apple.WebCore             	0x000000010ba02c7a void WTF::derefIfNotNull<WebCore::IDBClient::TransactionOperation>(WebCore::IDBClient::TransactionOperation*) + 58
7   com.apple.WebCore             	0x000000010ba02c33 WTF::RefPtr<WebCore::IDBClient::TransactionOperation>::~RefPtr() + 83
8   com.apple.WebCore             	0x000000010b9fcd85 WTF::RefPtr<WebCore::IDBClient::TransactionOperation>::~RefPtr() + 21
9   com.apple.WebCore             	0x000000010b9f9f5f WebCore::IDBClient::IDBConnectionProxy::completeOperation(WebCore::IDBResultData const&) + 223
10  com.apple.WebCore             	0x000000010ba262f2 WebCore::IDBClient::IDBConnectionToServer::didIterateCursor(WebCore::IDBResultData const&) + 98
11  com.apple.WebCore             	0x000000010bb4b7a0 WebCore::InProcessIDBServer::didIterateCursor(WebCore::IDBResultData const&)::$_16::operator()() const + 64
12  com.apple.WebCore             	0x000000010bb4b67c WTF::Function<void ()>::CallableWrapper<WebCore::InProcessIDBServer::didIterateCursor(WebCore::IDBResultData const&)::$_16>::call() + 28
13  com.apple.JavaScriptCore      	0x0000000105d098f3 WTF::Function<void ()>::operator()() const + 99
14  com.apple.JavaScriptCore      	0x0000000105d24fab WTF::RunLoop::performWork() + 219
15  com.apple.JavaScriptCore      	0x0000000105d25754 WTF::RunLoop::performWork(void*) + 36
16  com.apple.CoreFoundation      	0x00007fff8c2d7881 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
17  com.apple.CoreFoundation      	0x00007fff8c2b6fbc __CFRunLoopDoSources0 + 556
18  com.apple.CoreFoundation      	0x00007fff8c2b64df __CFRunLoopRun + 927
19  com.apple.CoreFoundation      	0x00007fff8c2b5ed8 CFRunLoopRunSpecific + 296
20  DumpRenderTree                	0x00000001047de21c runTest(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 6252 (DumpRenderTree.mm:2065)
21  DumpRenderTree                	0x00000001047dc8fd runTestingServerLoop() + 333 (DumpRenderTree.mm:1193)
22  DumpRenderTree                	0x00000001047dbe82 dumpRenderTree(int, char const**) + 450 (DumpRenderTree.mm:1307)
23  DumpRenderTree                	0x00000001047deb5d DumpRenderTreeMain(int, char const**) + 125 (DumpRenderTree.mm:1442)
24  DumpRenderTree                	0x0000000104837f72 main + 34 (DumpRenderTreeMain.mm:34)
25  libdyld.dylib                 	0x00007fff885bd5ad start + 1

[Brady Eidson]

This is a race, pure and simple. The operation completion has to happen on the background thread so quickly that it's done before the main thread that scheduled the background thread task even finishes doing so.

It's going to be difficult to write a dedicated test for.

But it will clear up random bot exposure in random workers tests.

[Brady Eidson]

Created attachment 282735 [details]
Patch

[WebKit Commit Bot]

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


ERROR: Source/WebCore/Modules/indexeddb/IDBActiveDOMObject.h:66:  Extra space before ( in function call  [whitespace/parens] [4]
Total errors found: 1 in 4 files


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

[Brady Eidson]

The Windows build breakage is not from this patch.

[WebKit Commit Bot]

Comment on attachment 282735 [details]
Patch

Clearing flags on attachment: 282735

Committed r202821: <http://trac.webkit.org/changeset/202821>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Csaba Osztrogonác]

(In reply to comment #5)
> Comment on attachment 282735 [details]
> Patch
> 
> Clearing flags on attachment: 282735
> 
> Committed r202821: <http://trac.webkit.org/changeset/202821>

(In reply to comment #4)
> The Windows build breakage is not from this patch.

It's not true, it broke the Apple Windows and WinCairo build too,
see build.webkit.org for details.

[Brady Eidson]

(In reply to comment #7)
> (In reply to comment #5)
> > Comment on attachment 282735 [details]
> > Patch
> > 
> > Clearing flags on attachment: 282735
> > 
> > Committed r202821: <http://trac.webkit.org/changeset/202821>
> 
> (In reply to comment #4)
> > The Windows build breakage is not from this patch.
> 
> It's not true, it broke the Apple Windows and WinCairo build too,
> see build.webkit.org for details.

Yup, sure did. I saw other errors when I looked at the EWS, but they were apparently just warnings.

[Alex Christensen]

Build should be fixed in r202836