[webkit-dev] DropAllLocks assertion on iOS (threading issue?)

[Ian Ragsdale]

Hello all, new member to the list, hopefully I'm in the right place.

I'm using WebKit in an iOS app (via UIWebView), and we're seeing a semi-frequent crash that I'm trying to track down. From the backtraces, I _think_ it appears to be a WebKit bug, and so I'd like to try to find a workaround, and/or submit a useful bug or patch.

A full thread dump is available here: http://crashes.to/s/cf0cdb52701

The assertion appears to be happening when the WebThread tries to call my delegate to decide whether to load a URL:

Thread : Crashed: WebThread
0  JavaScriptCore                 0x27e864aa WTFCrash + 53
1  JavaScriptCore                 0x27e86457 WTFPrintBacktrace + 130
2  JavaScriptCore                 0x27dc92e1 JSC::JSLock::DropAllLocks::DropAllLocks(JSC::VM*)
3  WebCore                        0x31cd3061 SendDelegateMessage(NSInvocation*) + 184
4  WebKitLegacy                   0x327be1f5 -[_WebSafeForwarder forwardInvocation:] + 116
5  CoreFoundation                 0x269d766f ___forwarding___ + 354
6  CoreFoundation                 0x26909058 _CF_forwarding_prep_0 + 24
7  WebKitLegacy                   0x327ffb01 WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction(WebCore::NavigationAction const&, WebCore::ResourceRequest const&, WTF::PassRefPtr<WebCore::FormState>, std::__1::function<void (WebCore::PolicyAction)>) + 344

From looking at the source, it tries to drop all locks from the current javascript VM before calling the delegate, and when it does that it asserts if the VM is busy garbage collecting. I'm guessing there needs to be some sort of guard there to make sure the VM isn't doing GC before dropping the locks?

I'm pretty positive I'm not calling into the UIWebView from any thread other than the main thread, and I don't think I have any control over the WebThread or the GC threads, so I'm not sure if there's anything I can do, but I do have a fairly reliable repro, so if there's something it makes sense for me to test, I can do so.

The one thing I can think of that could be causing issues on our end is that we're using a custom NSURLProtocol for loading some of the data, but I can't ever find it in the stack traces, so I don't think that's it.

Any suggestions?

Thanks in advance,
Ian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4829 bytes
Desc: not available
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20141211/b01f74d2/attachment.p7s>