RESOLVED FIXED138971
[iOS] allocate volume view on the main thread
https://bugs.webkit.org/show_bug.cgi?id=138971
Summary [iOS] allocate volume view on the main thread
Eric Carlson
Reported 2014-11-21 10:38:37 PST
The volume view used to check for wireless target availability should be allocated on the main thread.
Attachments
Proposed patch. (3.68 KB, patch)
2014-11-21 11:07 PST, Eric Carlson
no flags
Eric Carlson
Comment 1 2014-11-21 11:04:34 PST
Eric Carlson
Comment 2 2014-11-21 11:07:51 PST
Created attachment 242053 [details] Proposed patch.
WebKit Commit Bot
Comment 3 2014-11-21 13:22:35 PST
Comment on attachment 242053 [details] Proposed patch. Clearing flags on attachment: 242053 Committed r176471: <http://trac.webkit.org/changeset/176471>
WebKit Commit Bot
Comment 4 2014-11-21 13:22:42 PST
All reviewed patches have been landed. Closing bug.
Eric Carlson
Comment 5 2014-11-24 20:42:09 PST
*** Bug 138961 has been marked as a duplicate of this bug. ***
Daniel
Comment 6 2014-11-27 07:07:21 PST
This fix is not good. It deadlocks the app if the main thread is doing something related to the web view, because at the time of . We're getting this freeze quite often, and get different stacks in the main thread, ending with: thread #1: tid = 0x10919d, 0x33473ba8 libsystem_kernel.dylib`__psynch_mutexwait + 24, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x33473ba8 libsystem_kernel.dylib`__psynch_mutexwait + 24 frame #1: 0x334f103a libsystem_pthread.dylib`_pthread_mutex_lock + 394 frame #2: 0x307fdf20 WebCore`_WebTryThreadLock(bool) + 44 frame #3: 0x307fe736 WebCore`WebThreadLock + 82 While the WebThread will wait on dispatch_sync(dispatch_get_main_queue(), ...). The web thread is running, and locked so the main thread can't proceed to lock. The web thread can't proceed, with dispatch_sync, because the main thread is busy. Try using dispatch_async instead. This should do the trick if the _volumeView is not going to be used immediately in the WebThread.
Eric Carlson
Comment 7 2014-12-01 21:43:09 PST
(In reply to comment #6) > This fix is not good. It deadlocks the app if the main thread is doing > something related to the web view, because at the time of . > > We're getting this freeze quite often, and get different stacks in the main > thread, ending with: > > thread #1: tid = 0x10919d, 0x33473ba8 > libsystem_kernel.dylib`__psynch_mutexwait + 24, queue = > 'com.apple.main-thread', stop reason = signal SIGSTOP > * frame #0: 0x33473ba8 libsystem_kernel.dylib`__psynch_mutexwait + 24 > frame #1: 0x334f103a libsystem_pthread.dylib`_pthread_mutex_lock + 394 > frame #2: 0x307fdf20 WebCore`_WebTryThreadLock(bool) + 44 > frame #3: 0x307fe736 WebCore`WebThreadLock + 82 > > While the WebThread will wait on dispatch_sync(dispatch_get_main_queue(), > ...). The web thread is running, and locked so the main thread can't proceed > to lock. The web thread can't proceed, with dispatch_sync, because the main > thread is busy. > > Try using dispatch_async instead. This should do the trick if the > _volumeView is not going to be used immediately in the WebThread. Thank you for the information. Please feel free to submit patches if you have suggestions for changes.
Ian
Comment 8 2015-03-23 14:19:05 PDT
UIWebView frequently crashes on iOS because of this bug and the proposed patch does not fix the problem. A reproducible example has been provided with rdar://problem/18609955 The allocateVolumeView method checks for isMainThread() which is implemented as: (isWebThread() || pthread_main_np()) Since this is called from the web thread, isMainThread returns true. Also, MPVolumeView gets allocated twice in the case where isMainThread() is false. Once on the main thread and then another time on the background thread (which is what we are trying to avoid here).
Note You need to log in before you can comment on or make changes to this bug.