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

Reply via email to