IOS - determining the cause of the failure (from the crash report) in _WebTryThreadLock

Question

I am trying to figure out what causes one of the main crashes in my iOS application. There seems to be some kind of layout happening in the background thread that causes it to crash. Is there a way to determine what I can do, this triggers this repeater? I assume from the stack that this is due to the UIWebView when my application comes back to the fore.

Other stackoverflow threads in the topic seem to mention things like starting a table reload in the background thread. As far as I can see, all webView delegate methods are called in the main thread. Is there some case where this is not true or are there any other methods that are called in the background thread, and I just don't know?

Web Stream Fails.

0 WebCore _WebTryThreadLock(bool) + 297 1 WebCore _WebTryThreadLock(bool) + 288 2 WebCore WebThreadLock + 66 3 UIKit -[UIWebDocumentView(UIWebDocumentViewTextSelecting) selectionBaseWritingDirection] + 10 4 UIKit -[UITextField _currentTextAlignment] + 86 5 UIKit -[UITextField _showsClearButtonWhenNonEmpty:] + 58 6 UIKit -[UITextField _textRectForBounds:forEditing:] + 678 7 UIKit -[UITextField editingRectForBounds:] + 52 8 UIKit -[UITextField editRect] + 70 9 UIKit -[UITextField layoutSubviews] + 1320 10 UIKit -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 258 11 QuartzCore -[CALayer layoutSublayers] + 214 12 QuartzCore CA::Layer::layout_if_needed(CA::Transaction*) + 460 13 QuartzCore CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 16 14 QuartzCore CA::Context::commit_transaction(CA::Transaction*) + 238 15 QuartzCore CA::Transaction::commit() + 316 16 QuartzCore CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 60 17 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 20 18 CoreFoundation __CFRunLoopDoObservers + 276 19 CoreFoundation CFRunLoopRunSpecific + 394 20 CoreFoundation CFRunLoopRunInMode + 104 21 WebCore RunWebThread(void*) + 444 22 libsystem_c.dylib pthread_start + 308 

Main topic

 0 libsystem_kernel.dylib __psynch_mutexwait + 24 1 libsystem_c.dylib pthread_mutex_lock + 392 2 WebCore _WebTryThreadLock(bool) + 336 3 WebCore WebThreadLock + 66 4 WebKit -[WebDatabasePauser applicationWillEnterForeground] + 16 5 CoreFoundation _CFXNotificationPost + 1426 6 Foundation -[NSNotificationCenter postNotificationName:object:userInfo:] + 72 7 UIKit -[UIApplication _sendWillEnterForegroundCallbacks] + 154 8 UIKit -[UIApplication _handleApplicationResumeEvent:] + 1094 9 UIKit -[UIApplication handleEvent:withNewEvent:] + 1292 10 UIKit -[UIApplication sendEvent:] + 72 11 UIKit _UIApplicationHandleEvent + 6154 12 GraphicsServices _PurpleEventCallback + 590 13 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14 14 CoreFoundation __CFRunLoopDoSources0 + 212 15 CoreFoundation __CFRunLoopRun + 646 16 CoreFoundation CFRunLoopRunSpecific + 356 17 CoreFoundation CFRunLoopRunInMode + 104 18 GraphicsServices GSEventRunModal + 74 19 UIKit UIApplicationMain + 1120 20 AppName main.m line 23 

Answer 1

It seems you are updating the user interface in the background thread, in your code add this line wherever you update your interface, and you are extracting data in the background thread:

 dispatch_async(dispatch_get_main_queue(), ^{ // Update data here }); 

As soon as you, rather the code, feel that there is data on the device, and it is time to update the interface corresponding to the new data, then try to return the main stream to action.

Hope this helps.