DropAllLocks assertion on iOS (threading issue?)
Ian Ragsdale <ian.ragsdale <at> gmail.com>
2014-12-12 00:50:12 GMT
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
Thread : Crashed: WebThread
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
const&, WebCore::ResourceRequest const&, WTF::PassRefPtr<WebCore::FormState>,
std::__1::function<void (WebCore::PolicyAction)>) + 344
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.
Thanks in advance,
webkit-dev mailing list
webkit-dev <at> lists.webkit.org