Random crash on pickerview didSelect: __cfrunloop_is_calling_out_to_a_source1_perform1_function

Question

I received the following crash report, but I do not understand the problem. Line 487 indicates whether the pickerView in the delegate is a specific variable.

Crashed: com.apple.main-thread 0 App 0x1001c5208 specialized NewCorrectiveVC.pickerView(UIPickerView, didSelectRow : Int, inComponent : Int) -> () (NewCorrectiveVC.swift:487) 1 App 0x1001c2028 @objc NewCorrectiveVC.pickerView(UIPickerView, didSelectRow : Int, inComponent : Int) -> () (NewCorrectiveVC.swift) 2 UIKit 0x197a83154 -[UIPickerView _sendSelectionChangedForComponent:notify:] + 116 3 UIKit 0x197a8338c -[UIPickerView _sendSelectionChangedFromTable:notify:] + 344 4 UIKit 0x197fb0424 -[UIPickerTableView _scrollingFinished] + 188 5 UIKit 0x197fb05fc -[UIPickerTableView scrollViewDidEndDecelerating:] + 28 6 UIKit 0x197b216ac -[UIScrollView(UIScrollViewInternal) _scrollViewDidEndDeceleratingForDelegate] + 132 7 UIKit 0x1979b6db0 -[UIScrollView(UIScrollViewInternal) _stopScrollDecelerationNotify:] + 332 8 UIKit 0x1979b68ec -[UIScrollView _smoothScrollWithUpdateTime:] + 2356 9 QuartzCore 0x194bc01bc CA::Display::DisplayLinkItem::dispatch(unsigned long long) + 44 10 QuartzCore 0x194bc0068 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 444 11 IOKit 0x191c27138 IODispatchCalloutFromCFMessage + 372 12 CoreFoundation 0x19195056c __CFMachPortPerform + 180 13 CoreFoundation 0x191968934 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 56 14 CoreFoundation 0x1919680e8 __CFRunLoopDoSource1 + 436 15 CoreFoundation 0x191965bcc __CFRunLoopRun + 1840 16 CoreFoundation 0x191894048 CFRunLoopRunSpecific + 444 17 GraphicsServices 0x19331a198 GSEventRunModal + 180 18 UIKit 0x1978792fc -[UIApplication _run] + 684 19 UIKit 0x197874034 UIApplicationMain + 208 20 App 0x100173d04 main (AppDelegate.swift:22) 21 libdispatch.dylib 0x1908785b8 (Missing) 

the code:

 func pickerView(_ pickerView: UIPickerView, didSelectRow row: Int, inComponent component: Int) { if pickerView == assignedTo { if employees.count > 0 { selectedEmp = employees[row].employeeId } } else if pickerView == category \\this is line 487 { if categories.count > 0 { selectedCat = categories[row].wocategoryId } } } 

EDIT:

Not sure if the following is relevant, but I have observers related to my pickerViews:

 let longPressRecognizer = UILongPressGestureRecognizer(target: self, action: #selector(self.longPressed)) assignedTo.addGestureRecognizer(longPressRecognizer) let catLongPressRecognizer = UILongPressGestureRecognizer(target: self, action: #selector(self.catLongPressed)) category.addGestureRecognizer(catLongPressRecognizer) self.hideKeyboardWhenTappedAround() self.scroll.keyboardDismissMode = .interactive 

FYI:

 public func hideKeyboardWhenTappedAround() { let tap: UITapGestureRecognizer = UITapGestureRecognizer(target: self, action: #selector(UIViewController.dismissKeyboard)) view.addGestureRecognizer(tap) } 

Answer 1

I suspect the problem is calling == .

 if pickerView == assignedTo 

This does not mean what you mean. This calls the == function call and tries to evaluate the equality between the two objects. If one of them is nil , that will work.

pickerView should never be nil , but I have seen cases where UIKit sends nil for parameters that should never be nil . (This can especially happen if there are any calls to UIKit methods in background threads. Be very careful not to do this, but it can also happen due to UIKit errors.)

assignedTo may be nil if the view is not loaded. Theoretically, you should never get this call in this case, but again, this is possible if there are errors, most often due to calling UIKit methods from the main thread (any UIKit methods that do not always have to be associated with this particular kind of choice) , but UIKit sometimes has its own mistakes.

In any case, you do not mean that "this is a pickerView equal to that assigned." You mean "this pickerView is exactly as intended." This === :

 if pickerView === assignedTo 

=== compares the pointer, so even in the case of an invalid nil it is safe.

Keep in mind that this is almost certainly related to race conditions. The fact that it is not easily reproduced when you run it in the debugger does not mean anything. This can happen once in 10k attempts, only in Release, exclusively on iPhone 6. This is the nature of the race conditions.