Re: [webkit-dev] DropAllLocks assertion on iOS (threading issue?)
Actually, looking again, I was running the profile on the device, not the simulator as I had meant to. One other thing I meant to mention is that I keep three instances of the UIWebView loaded, and I trigger it by paging between them quickly, so perhaps it's an issue with multiple instances? There is always one on screen, and paging from one to the next allocates a new one while an old one is discarded. They all appear to share the same WebThread & JavaScript threads, so I could see that being problematic. - Ian On Dec 11, 2014, at 9:25 PM, Ian Ragsdale wrote: > > Hi Geoff, thanks for the quick response! > > I don't believe I'm making any use of SPI, aside from whatever underlying use > there is in UIWebView - I'm pretty sure that's not exposed to normal iOS apps > (at least not that I'm aware of). > > As predicted, setting JSC_slowPathAllocsBetweenGCs does appear to make it > easier to trigger the crash. I did that and then did an Instruments sample > using the iOS simulator, and got the crash to happen pretty quickly. However, > I'm not really sure what to look for, since I'm a newbie to WebKit internals. > Any suggestions for what to look for in the call tree? > > Thanks again, > Ian > >> On Dec 11, 2014, at 8:11 PM, Geoffrey Garen wrote: >> >> Hi Ian. >> >>> 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. >> >> That’s right. >> >>> 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? >> >> In JavaScriptCore, garbage collection is an atomic operation that must run >> to completion before the next allocation. >> >> The reason this is an assertion — and can’t be a guard — is that, if we >> called out to a delegate in the middle of garbage collection, we would >> definitely corrupt the heap. So, there’s nothing you can guard against: the >> game is already lost. >> >> The bug here happened earlier: Somehow, the collector was left thinking that >> it was in the busy state, even though — as we can see from the backtrace — >> it wasn’t actually doing anything. >> >>> 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. >> >> Does you app make any use of WebKit SPI? If it does, the SPI might not be >> thread-safe even if called from the main thread, and so you might be >> corrupting the heap. >> >> One technique that might make this bug more reproducible is to set the >> environment variable JSC_slowPathAllocsBetweenGCs to a low number (as low as >> possible without making your app unusable) — that will trigger collection >> more frequently. >> >> Another thing you can try is to record an Instruments time profile of the >> app as you go through the steps to make the app crash. That will give us an >> overview of what the app was doing leading up to the crash, whether it used >> UIWebView from a secondary thread or invoked SPI, and so on. >> >> Geoff > smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DropAllLocks assertion on iOS (threading issue?)
Hi Geoff, thanks for the quick response! I don't believe I'm making any use of SPI, aside from whatever underlying use there is in UIWebView - I'm pretty sure that's not exposed to normal iOS apps (at least not that I'm aware of). As predicted, setting JSC_slowPathAllocsBetweenGCs does appear to make it easier to trigger the crash. I did that and then did an Instruments sample using the iOS simulator, and got the crash to happen pretty quickly. However, I'm not really sure what to look for, since I'm a newbie to WebKit internals. Any suggestions for what to look for in the call tree? Thanks again, Ian > On Dec 11, 2014, at 8:11 PM, Geoffrey Garen wrote: > > Hi Ian. > >> 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. > > That’s right. > >> 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? > > In JavaScriptCore, garbage collection is an atomic operation that must run to > completion before the next allocation. > > The reason this is an assertion — and can’t be a guard — is that, if we > called out to a delegate in the middle of garbage collection, we would > definitely corrupt the heap. So, there’s nothing you can guard against: the > game is already lost. > > The bug here happened earlier: Somehow, the collector was left thinking that > it was in the busy state, even though — as we can see from the backtrace — it > wasn’t actually doing anything. > >> 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. > > Does you app make any use of WebKit SPI? If it does, the SPI might not be > thread-safe even if called from the main thread, and so you might be > corrupting the heap. > > One technique that might make this bug more reproducible is to set the > environment variable JSC_slowPathAllocsBetweenGCs to a low number (as low as > possible without making your app unusable) — that will trigger collection > more frequently. > > Another thing you can try is to record an Instruments time profile of the app > as you go through the steps to make the app crash. That will give us an > overview of what the app was doing leading up to the crash, whether it used > UIWebView from a secondary thread or invoked SPI, and so on. > > Geoff smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DropAllLocks assertion on iOS (threading issue?)
Hi Ian. > 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. That’s right. > 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? In JavaScriptCore, garbage collection is an atomic operation that must run to completion before the next allocation. The reason this is an assertion — and can’t be a guard — is that, if we called out to a delegate in the middle of garbage collection, we would definitely corrupt the heap. So, there’s nothing you can guard against: the game is already lost. The bug here happened earlier: Somehow, the collector was left thinking that it was in the busy state, even though — as we can see from the backtrace — it wasn’t actually doing anything. > 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. Does you app make any use of WebKit SPI? If it does, the SPI might not be thread-safe even if called from the main thread, and so you might be corrupting the heap. One technique that might make this bug more reproducible is to set the environment variable JSC_slowPathAllocsBetweenGCs to a low number (as low as possible without making your app unusable) — that will trigger collection more frequently. Another thing you can try is to record an Instruments time profile of the app as you go through the steps to make the app crash. That will give us an overview of what the app was doing leading up to the crash, whether it used UIWebView from a secondary thread or invoked SPI, and so on. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] DropAllLocks assertion on iOS (threading issue?)
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 WebCore0x31cd3061 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, std::__1::function) + 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 smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
