Can you attach the Instruments trace leading up to the crash, and/or a reduced copy of the app that can reproduce the crash, to bugzilla?
Thanks, Geoff > On Dec 11, 2014, at 7:34 PM, Ian Ragsdale <ian.ragsd...@gmail.com> wrote: > > 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 >> > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
