Weird Swift crash stack

gistfile1.txt

Crashed: com.apple.main-thread
EXC_BREAKPOINT 0x00000000e7ffdefe
Thread : Crashed: com.apple.main-thread
0  MyApp                         0x210ac4 specialized CartTableViewController.tableView(UITableView, titleForDeleteConfirmationButtonForRowAtIndexPath : NSIndexPath) -> String? (CartTableViewController.swift:190)
1  MyApp                         0x2106bc specialized CartTableViewController.tableView(UITableView, titleForDeleteConfirmationButtonForRowAtIndexPath : NSIndexPath) -> String? (CartTableViewController.swift:184)
2  MyApp                         0x20d990 @objc CartTableViewController.tableView(UITableView, titleForDeleteConfirmationButtonForRowAtIndexPath : NSIndexPath) -> String? (CartTableViewController.swift)
3  UIKit                          0x2726acbb -[UITableView _titleForDeleteConfirmationButtonForRowAtIndexPath:] + 146
4  UIKit                          0x27392f4f -[UITableView _deleteConfirmationButtonForRowAtIndexPath:] + 102
5  UIKit                          0x27393483 -[UITableView _swipeActionButtonsForRowAtIndexPath:] + 726
6  UIKit                          0x27393193 -[UITableView _swipeActionButtons] + 90
7  UIKit                          0x2726a6c3 __32-[UITableViewCell _beginSwiping]_block_invoke + 178
8  UIKit                          0x2706f651 +[UIView(Animation) performWithoutAnimation:] + 72
9  UIKit                          0x2726a601 -[UITableViewCell _beginSwiping] + 92
10 UIKit                          0x2738feed -[UITableViewWrapperView handleSwipeBeginning:] + 248
11 UIKit                          0x275b72fd _UIGestureRecognizerSendTargetActions + 352
12 UIKit                          0x2720034f _UIGestureRecognizerSendActions + 170
13 UIKit                          0x27092da7 -[UIGestureRecognizer _updateGestureWithEvent:buttonEvent:] + 578
14 UIKit                          0x275b858f ___UIGestureRecognizerUpdate_block_invoke904 + 62
15 UIKit                          0x27053d97 _UIGestureRecognizerRemoveObjectsFromArrayAndApplyBlocks + 298
16 UIKit                          0x27050367 _UIGestureRecognizerUpdate + 2902
17 CoreFoundation                 0x22ee6f59 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 20
18 CoreFoundation                 0x22ee525d __CFRunLoopDoObservers + 280
19 CoreFoundation                 0x22ee568f __CFRunLoopRun + 958
20 CoreFoundation                 0x22e38bf9 CFRunLoopRunSpecific + 520
21 CoreFoundation                 0x22e389e5 CFRunLoopRunInMode + 108
22 GraphicsServices               0x24084ac9 GSEventRunModal + 160
23 UIKit                          0x270c8ba1 UIApplicationMain + 144
24 MyApp                         0xa7ca7 main (main.m:35)
25 libdispatch.dylib              0x22ae7873 (Missing)

Thanks for the response, Matt.

I've seen a lot of tough C++ stacks too and the inlining/specialization can be rough. Often times I can identify the inlined function calls in Swift even if the line numbers can be off. Your point about inlines looking like recursion is a good explanation. They're definitely easier to identify in ObjC though.

I was looking for unwrapped optionals as well (pretty much our go-to for crash debugging in the project) and while there is one on CartTableViewController.swift:184 there is not one on the line the crashed CartTableViewController.swift:190. 190 is actually a plan old case statement with no operations:

183  override func tableView(tableView: UITableView, titleForDeleteConfirmationButtonForRowAtIndexPath indexPath: NSIndexPath) -> String? {
184      let cartItem = self.dataSource!.sections[indexPath.section][indexPath.row]
185      switch(cartItem) {
186      case .Contact:
187          return NSLocalizedString("Remove", comment: "...")
188      case .LineItem, .Discount:
189          return NSLocalizedString("Delete", comment: "...")
190      case .Tax, .BarcodeSKU:
191          return nil
192      }
193  }

Given that, if the ! was the problem, I would have expected the stack to be 190 followed by 184 or just 184 with 190 never being reached. ¯_(ツ)_/¯

There doesn't appear to be any additional logging with this crash, which was part of a Release build. We attach some user account details through Crashlytics, but don't have any info about what lead up to this. Plus, this crash has only happened once.

I agree that a single crash like this probably isn't worth much time to examine, but it seemed like a strange case that could inform how we interpret other Swift stacks in the future. Thanks again for your feedback, I really appreciate it.

You're very welcome! I agree that the dataSource being nil is probably the issue. If you're feeling really curious, you can try manually constructing a case where the dataSource is nil, build in release and see what the debugger says. I'd love to see that too.

I am facing a similar problem. (More details: http://stackoverflow.com/questions/37276942/swift-specialised-crash-on-uicollectionview-cellforitematindexpath)
Did anyone find a reason for the problem ?