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 <ian.ragsd...@gmail.com> 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 <gga...@apple.com> 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
