Ok, I've created a new bug with the instruments trace here: https://bugs.webkit.org/show_bug.cgi?id=139654 <https://bugs.webkit.org/show_bug.cgi?id=139654>
I'll see what I can do about a sample project soon. I've also got a bit of new information to share. We released a new beta of the app in which this bug went from infrequent to very frequent (from 8 crashes in ~6k sessions to 160 crashes in ~5k sessions). Very little in the app had changed - some CSS changes, some minor Javascript changes (animating a width change and a few more style changes in a completion callback), and a change to how we detect the initial document load is complete. However, that was enough for a huge spike in crashes. This was interesting because while the stack trace of the crashed thread varied, 156 of the 160 crashes showed the same backtrace for the main thread: Thread : com.apple.main-thread 0 libsystem_kernel.dylib 0x2fe05ba8 __psynch_mutexwait + 24 1 libsystem_pthread.dylib 0x2fe8104b _pthread_mutex_lock + 398 2 WebCore 0x2d353b91 _WebTryThreadLock(bool) + 44 3 WebCore 0x2d3543ad WebThreadLock + 80 4 UIKit 0x2561ca69 -[UIWebDocumentView setDataDetectorTypes:] + 56 5 Boxer 0x000cc245 -[ConversationViewController renderConversation] (ConversationViewController.m:869) 6 libdispatch.dylib 0x2fd1f7bb _dispatch_call_block_and_release + 10 7 libdispatch.dylib 0x2fd1f7a7 _dispatch_client_callout + 22 8 libdispatch.dylib 0x2fd22fa3 _dispatch_main_queue_callback_4CF + 718 9 CoreFoundation 0x21fcf3b1 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8 10 CoreFoundation 0x21fcdab1 __CFRunLoopRun + 1512 11 CoreFoundation 0x21f1b3c1 CFRunLoopRunSpecific + 476 12 CoreFoundation 0x21f1b1d3 CFRunLoopRunInMode + 106 13 GraphicsServices 0x293190a9 GSEventRunModal + 136 14 UIKit 0x2552afa1 UIApplicationMain + 1440 15 Boxer 0x000900a7 main (main.m:11) (More details here: http://crashes.to/s/b1531e29971 <http://crashes.to/s/b1531e29971>) It's an easy workaround to avoid this crash, but I think it may help tracking down whatever this race condition might be. Hope this helps, Ian > On Dec 15, 2014, at 1:51 PM, Geoffrey Garen <gga...@apple.com> wrote: > > 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
