Bug 209437 - Assertion triggered on iOS 13: Multiple locks on web thread
Summary: Assertion triggered on iOS 13: Multiple locks on web thread
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: Safari 13
Hardware: iPhone / iPad iOS 13
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-03-23 14:10 PDT by Darren Mo
Modified: 2020-03-25 19:37 PDT (History)
5 users (show)

See Also:

Attachments
Stack trace on (iPhone9,3 13.3.1 17D50) (27.03 KB, text/plain)
2020-03-23 14:10 PDT, Darren Mo 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Darren Mo 2020-03-23 14:10:22 PDT 
Created attachment 394302 [details]
Stack trace on (iPhone9,3 13.3.1 17D50)

Starting in iOS 13 and still occurring in iOS 13.4, an assertion in `_WebThreadLock` is being hit: `Multiple locks on web thread not allowed! Please file a bug. Crashing now...`.

The attached stack trace points to the following `WebCore` code:
```
                     __ZL14_WebThreadLockv.cold.1:        // _WebThreadLock() [clone .cold.1]
0000000189ab5708         sub        sp, sp, #0x20                               ; CODE XREF=__ZL14_WebThreadLockv+336
0000000189ab570c         stp        x29, x30, [sp, #0x10]
0000000189ab5710         add        x29, sp, #0x10
0000000189ab5714         bl         __ZL20CurrentThreadContextv                 ; CurrentThreadContext()
0000000189ab5718         adrp       x8, #0x189b51000                            ; 0x189b51340@PAGE
0000000189ab571c         add        x8, x8, #0x340                              ; 0x189b51340@PAGEOFF, "void _WebThreadLock()"
0000000189ab5720         stp        x8, x0, [sp]
0000000189ab5724         adrp       x0, #0x1bf154000                            ; 0x1bf154850@PAGE
0000000189ab5728         add        x0, x0, #0x850                              ; 0x1bf154850@PAGEOFF, @"%s, %p: Multiple locks on web thread not allowed! Please file a bug. Crashing now..."
0000000189ab572c         bl         imp___stubs___ZNK2sh14TConstantUniongtERKS0_ ; sh::TConstantUnion::operator>(sh::TConstantUnion const&) const
0000000189ab5730         brk        #0x0
0000000189ab5734         brk        #0x1
```

We do not have information about what was happening in the app prior to the crash aside from the attached stack trace.
Comment 1 Alexey Proskuryakov 2020-03-24 22:11:37 PDT 
Would you be able to characterize customer impact, and whether this app can move to modern WebKit API?
Comment 2 Radar WebKit Bug Importer 2020-03-24 22:11:46 PDT 
<rdar://problem/60858737>
Comment 3 Darren Mo 2020-03-25 11:58:29 PDT 
(In reply to Alexey Proskuryakov from comment #1)
> Would you be able to characterize customer impact, and whether this app can
> move to modern WebKit API?

We’ve been seeing this crash for years. ~340k crash reports since 2016.

We are using iOS’s `UIWebView`. By “modern WebKit API”, do you mean `WKWebView`?
Comment 4 Alexey Proskuryakov 2020-03-25 13:07:31 PDT 
> We are using iOS’s `UIWebView`. By “modern WebKit API”, do you mean `WKWebView`?

Correct.
Comment 5 Darren Mo 2020-03-25 13:59:33 PDT 
(In reply to Alexey Proskuryakov from comment #4)
> > We are using iOS’s `UIWebView`. By “modern WebKit API”, do you mean `WKWebView`?
> 
> Correct.

We are in the process of migrating now. To be clear, this crash will not occur when using `WKWebView`, right? Is this a known issue with `UIWebView`?
Comment 6 Alexey Proskuryakov 2020-03-25 18:13:09 PDT 
WebThread isn't used with WKWebView (it uses a separate process for web content), so this issue definitely won't happen.

I don't know if it's necessarily a legacy WebKit bug - searching the Web for "Multiple locks on web thread not allowed", I see many hits explaining programming model violations in client code that can lead to this. But legacy WebKit certainly has architectural threading issues of its own too.
Comment 7 Darren Mo 2020-03-25 19:37:04 PDT 
Great, thanks! I will mark this bug as resolved then.