Crashed at <compiler-generated> line 0

Hi, according to fabric report. There is a crash which I think is related to didSelectRowAt. May I know what is the crash means?

Crashed: com.apple.main-thread
0  MyApp                          0x1005e7cc4 $S8MyApp8SearchVCC9tableView_14didSelectRowAtySo07UITableF0C_10Foundation9IndexPathVtFTf4dnn_n (<compiler-generated>)
1  MyApp .                        0x1005e2fa8 $S8MyApp8SearchVCC9tableView_14didSelectRowAtySo07UITableF0C_10Foundation9IndexPathVtFTo (<compiler-generated>)
2  UIKit                          0x18b1b8b20 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 1352
3  UIKit                          0x18b261760 -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 268
4  UIKit                          0x18b30faa8 _runAfterCACommitDeferredBlocks + 292
5  UIKit                          0x18b302e5c _cleanUpAfterCAFlushAndRunDeferredBlocks + 288
6  UIKit                          0x18b094464 _afterCACommitHandler + 132
7  CoreFoundation                 0x181a8ecdc __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32
8  CoreFoundation                 0x181a8c694 __CFRunLoopDoObservers + 412
9  CoreFoundation                 0x181a8cc50 __CFRunLoopRun + 1292
10 CoreFoundation                 0x1819acc58 CFRunLoopRunSpecific + 436
11 GraphicsServices               0x183858f84 GSEventRunModal + 100
12 UIKit                          0x18b1055c4 UIApplicationMain + 236
13 MyApp .                        0x1005b36a4 main (History+CoreDataProperties.swift:16)
14 libdyld.dylib                  0x1814cc56c start + 4

Replies

You see a line number of 0 when you crash in code the compiler generated on your behalf. See this post for more on that.

As to what’s happening in your specific case, it’s hard to say without more details. Do you have an Apple crash report for this?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hi! I got a similar crash here. Just appeared after my latest release which was the first one built with Xcode 10.1, with no changes to anywhere near the crashing part. Basically what seems to crash is the call to a function I defined as


func generateQuestion(replay: Bool = false) -> Question


The line which calls this function is the last one mentioned by number, and above it in the stacktrace there's <compiler-generated> line 0 for this function. I'm calling it with an explicit replay param, but still I think my best guess would be to remove the default value of the boolean param?

I think my best guess would be to remove the default value of the boolean param?

You could try that, but I don’t think it will help.

Do you have an Apple crash report for this crash? If so, please post it and I’ll take a more in-depth look.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I don't think I have an Apple crash report — the crashes only occurred on some users and I saw them in Fabric. The Crashes tab in Xcode's Organizer is empty (and the version picker doesn't even list this version, which I released last week, only the previous ones). Can I somehow dig them up somewhere still?

Can I somehow dig them up somewhere still?

I don’t know (I’ve never used a third-party crash reporter). However, this is something you can test: Just add a button to your app that forces a crash and see if that generates both types of crash report. If your third-party crash reporter is blocking Apple crash reports, or messing them up so that they don’t include accurate state information for the crashed thread, it’s time to find a better third-party crash reporter.

Alternatively, ship a build of your app without the third-party crash reporter and see what you get back via the Apple crash reporter.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I've faced the same exact issue. Here how it looks from a Fabric report file:


Crashed: com.apple.main-thread
0  My App                 0x100ddb618 $S13My_App20SearchViewControllerC05tableD0_14didSelectRowAtySo07UITableD0C_10Foundation9IndexPathVtF ()
1  My App                 0x100ddb67c $S13My_App20SearchViewControllerC05tableD0_14didSelectRowAtySo07UITableD0C_10Foundation9IndexPathVtFTo ()
2  UIKit                          0x18cef2bb4 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 1352
3  UIKit                          0x18cf9b7f4 -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 268
4  UIKit                          0x18d049b3c _runAfterCACommitDeferredBlocks + 292
5  UIKit                          0x18d03cef0 _cleanUpAfterCAFlushAndRunDeferredBlocks + 288
6  UIKit                          0x18cdce54c _afterCACommitHandler + 132
7  CoreFoundation                 0x1838a1edc __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32
8  CoreFoundation                 0x18389f894 __CFRunLoopDoObservers + 412
9  CoreFoundation                 0x18389fe50 __CFRunLoopRun + 1292
10 CoreFoundation                 0x1837bfe58 CFRunLoopRunSpecific + 436
11 GraphicsServices               0x18566cf84 GSEventRunModal + 100
12 UIKit                          0x18ce3f67c UIApplicationMain + 236
13 My App                 0x100dbd718 main (ForYouDataSource.swift:12)
14 libdyld.dylib                  0x1832dc56c start + 4

And what is interesting, the dSYM file itself is corrupted. It contains all of those extra characters. Here is an example: http://piccy.info/view3/12804310/8e70abcef4ba801cfa44307b51105512/ That mean it's not a problem of 3rd party crash reporting library. Both dSYM files created by Xcode and downloaded from iTunes are corrupted in a such way.

All that happens for the build generated for the AppStore distribution with bitcode option enabled.


My assumption it can be linked to using/not_using new build system introduced for Xcode 10. What do you think?

And what is interesting, the dSYM file itself is corrupted. It contains all of those extra characters.

What extra characters are you talking about? I looked at your screen shot and I don’t see anything anomalous. Are you referring to the

_$S13
stuff?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Yes. I've noticed previously generated dSYM files contains "t __T013" instead of "t _$S13" and reports for that dSYM file were just Ok. Also i"ve tried to create a build using "Legacy Build System" but still without luck for correct symbolication. In addition I have an Apple crash report and I'm not able to navigate to the line of code which cause crash. Screenshots: http://i.piccy.info/i9/56daf8329a3148149632644958c99a66/1543575246/108433/1285538/Screen_Shot_2018_11_30_at_12_52_18_PM.png

I've faced the same exact issue. Here how it looks from a Fabric report file:


#0. Crashed: com.apple.main-thread
0  MyApp                      0x1015405c4 $S9MyApp14ShoppingCartVCC9tableView_12cellForRowAtSo07UITableG4CellCSo0lG0C_10Foundation9IndexPathVtFTf4dnn_n ()
1  MyApp                      0x10153cf74 $S9MyApp14ShoppingCartVCC9tableView_12cellForRowAtSo07UITableG4CellCSo0lG0C_10Foundation9IndexPathVtFTo ()
2  UIKitCore                      0x1dd2d8540 -[UITableView _createPreparedCellForGlobalRow:withIndexPath:willDisplay:] + 684
3  UIKitCore                      0x1dd2d8a88 -[UITableView _createPreparedCellForGlobalRow:willDisplay:] + 80
4  UIKitCore                      0x1dd2a4160 -[UITableView _updateVisibleCellsNow:isRecursive:] + 2256
5  UIKitCore                      0x1dd2c204c -[UITableView layoutSubviews] + 140
6  UIKitCore                      0x1dd556ea4 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1380
7  QuartzCore                     0x1b461ec70 -[CALayer layoutSublayers] + 184
8  QuartzCore                     0x1b4623c00 CA::Layer::layout_if_needed(CA::Transaction*) + 324
9  QuartzCore                     0x1b4582718 CA::Context::commit_transaction(CA::Transaction*) + 340
10 QuartzCore                     0x1b45b104c CA::Transaction::commit() + 608
11 UIKitCore                      0x1dd0da01c _afterCACommitHandler + 256
12 CoreFoundation                 0x1affbb7a8 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32
13 CoreFoundation                 0x1affb643c __CFRunLoopDoObservers + 412
14 CoreFoundation                 0x1affb69dc __CFRunLoopRun + 1264
15 CoreFoundation                 0x1affb61cc CFRunLoopRunSpecific + 436
16 GraphicsServices               0x1b222d584 GSEventRunModal + 100
17 UIKitCore                      0x1dd0b1054 UIApplicationMain + 212
18 LeJourney                      0x1013ae71c main (PostListViewController.swift:26)
19 libdyld.dylib                  0x1afa76bb4 start + 4

Here how it looks from a Fabric report file

If your third-party crash reporter isn’t behaving correctly, that’s something you need to take up with that third-party vendor.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I've noticed previously generated dSYM files contains "t __T013" instead of "t _$S13" and reports for that dSYM file were just Ok.

These weird format strings look like Swift mangled names (see this and this for more background). I believe that the Swift name mangling format is undergoing change as part of the ABI compatibility effort, and thus you may see symbolication problems until all the various tools catch up.

You can demangle names using the

swift-demangle
tool. For example, I created an app with code like this:
class SearchViewController : UITableViewController {
    override func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        fatalError()
    }
}

Xcode 10.1 mangles this to the following strings:

$ nm My_App.app/My_App | grep SearchViewController.*didSelect
0000000100001610 T _$S6My_App20SearchViewControllerC05tableD0_14didSelectRowAtySo07UITableD0C_10Foundation9IndexPathVtF
00000001000016a0 t _$S6My_App20SearchViewControllerC05tableD0_14didSelectRowAtySo07UITableD0C_10Foundation9IndexPathVtFTo

The

swift-demangle
tool understands these just fine:
$ xcrun swift-demangle -- '_$S6My_App20SearchViewControllerC05tableD0_14didSelectRowAtySo07UITableD0C_10Foundation9IndexPathVtF'
_$S6My_App20SearchViewControllerC05tableD0_14didSelectRowAtySo07UITableD0C_10Foundation9IndexPathVtF 
---> My_App.SearchViewController.tableView(_: __C.UITableView, didSelectRowAt: Foundation.IndexPath) -> ()
$ xcrun swift-demangle -- '_$S6My_App20SearchViewControllerC05tableD0_14didSelectRowAtySo07UITableD0C_10Foundation9IndexPathVtFTo'
_$S6My_App20SearchViewControllerC05tableD0_14didSelectRowAtySo07UITableD0C_10Foundation9IndexPathVtFTo 
---> @objc My_App.SearchViewController.tableView(_: __C.UITableView, didSelectRowAt: Foundation.IndexPath) -> ()

The

swift-demangle
tool does not understand the names in your crash report. I suspect that’s because you’ve redacted your app name, that is, changed the real app name from something that was 8 characters long to
MyApp
, which is only 6. I fixed that and now I see reasonable results:
$ xcrun swift-demangle -- '$S8MyAppXXX8SearchVCC9tableView_14didSelectRowAtySo07UITableF0C_10Foundation9IndexPathVtFTf4dnn_n'
$S8MyAppXXX8SearchVCC9tableView_14didSelectRowAtySo07UITableF0C_10Foundation9IndexPathVtFTf4dnn_n 
---> function signature specialization <Arg[0] = Dead> of MyAppXXX.SearchVC.tableView(_: __C.UITabletable, didSelectRowAt: Foundation.IndexPath) -> ()
$ xcrun swift-demangle -- '$S8MyAppXXX8SearchVCC9tableView_14didSelectRowAtySo07UITableF0C_10Foundation9IndexPathVtFTo'
$S8MyAppXXX8SearchVCC9tableView_14didSelectRowAtySo07UITableF0C_10Foundation9IndexPathVtFTo 
---> @objc MyAppXXX.SearchVC.tableView(_: __C.UITabletable, didSelectRowAt: Foundation.IndexPath) -> ()

In addition I have an Apple crash report and I'm not able to navigate to the line of code which cause crash.

I’m sorry but I’m not sure what you’re getting at with these screen shots.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks for the example of how to demangle those strings. Sorry for redacting original app name, it's 13 characters long. It's clear enough the porblem is in the way how 3rd party library is handling latest Xcode 10 generated dSYM files.


Regarding issue with an Apple crash report it's look like offttopic here, I'll create separate discussion once I'll collect more details if any.

I've been getting this kind of reports as well since mid-December.

Here's the apple crash.


Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x0000000100c7b53c
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [24932]
Triggered by Thread:  0


Thread 0 name:
Thread 0 Crashed:
0   MyApp                          0x0000000100c7b53c DiscoverViewController.tableView(_:cellForRowAt:) + 1732 (<compiler-generated>:0)
1   MyApp                          0x0000000100c7b5b0 @objc DiscoverViewController.tableView(_:cellForRowAt:) + 96 (<compiler-generated>:0)
2   UIKitCore                      0x0000000219fbc540 -[UITableView _createPreparedCellForGlobalRow:withIndexPath:willDisplay:] + 684 (UITableView.m:13737)
3   UIKitCore                      0x0000000219fbca88 -[UITableView _createPreparedCellForGlobalRow:willDisplay:] + 80 (UITableView.m:13788)
4   UIKitCore                      0x0000000219f880d0 -[UITableView _updateVisibleCellsNow:isRecursive:] + 2112 (UITableView.m:2641)
5   UIKitCore                      0x0000000219fa604c -[UITableView layoutSubviews] + 140 (UITableView.m:8744)
6   UIKitCore                      0x000000021a23aea4 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1380 (UIView.m:15694)
7   QuartzCore                    0x00000001f1186c70 -[CALayer layoutSublayers] + 184 (CALayer.mm:9445)
8   QuartzCore                    0x00000001f118bc00 CA::Layer::layout_if_needed(CA::Transaction*) + 324 (CALayer.mm:9325)
9   QuartzCore                    0x00000001f10ea718 CA::Context::commit_transaction(CA::Transaction*) + 340 (CALayer.mm:2463)
10  QuartzCore                    0x00000001f111904c CA::Transaction::commit() + 608 (CATransactionInternal.mm:425)
11  QuartzCore                    0x00000001f1119eb4 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 92 (CATransactionInternal.mm:795)
12  CoreFoundation                0x00000001ecb237a8 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32 (CFRunLoop.c:1822)
13  CoreFoundation                0x00000001ecb1e43c __CFRunLoopDoObservers + 412 (CFRunLoop.c:1932)
14  CoreFoundation                0x00000001ecb1e9dc __CFRunLoopRun + 1264 (CFRunLoop.c:2950)
15  CoreFoundation                0x00000001ecb1e1cc CFRunLoopRunSpecific + 436 (CFRunLoop.c:3247)
16  GraphicsServices              0x00000001eed95584 GSEventRunModal + 100 (GSEvent.c:2245)
17  UIKitCore                      0x0000000219d95054 UIApplicationMain + 212 (UIApplication.m:4347)
18  MyApp                          0x0000000100c54164 main + 60 (EventsTableViewCell.swift:21)
19  libdyld.dylib                  0x00000001ec5debb4 start + 4

The exception type of

EXC_BREAKPOINT
makes it very likely that this is a Swift trap. That is, code generated by the Swift compiler has detected some sort of precondition failure and stopped your process. There are a bunch of possible precondition failures that can occur, for example, a force unwrap of
nil
or an out of bounds array access.

The backtrace you posted does contain some useful info. Frame 1 is compiler-generated code that adapts the Swift native implementation of

DiscoverViewController.tableView(_:cellForRowAt:)
to its Objective-C equivalent. This is being called by frame 2, that is, UIKit. So UIKit (frame 2) has called the
tableView(_:cellForRowAt:)
data source method (frame 1), which is a compiler-generated Objective-C method that’s then called your Swift implementation of that method.

There’s two possibilities here:

  • The compiler-generated Objective-C method has detected a precondition failure and trapped (A).

    Note You will see this sort of thing if, for example, you declare an

    IBAction
    to take a parameter of type X and the actual parameter is of type Y.
  • The trap is in your code (B).

My best guess is that B applies here. That’s because in case A you’d usually expect the trap to be in the compiler-generated Objective-C method. That is, what’s shown in frame 1 in your backtrace would be frame 0.

The weird part here is that frame 0 is also compiler generated. Also, look at the offset into that method (+ 1732), which means it’s likely been placed by the compiler after your method. Normally such code woud be called by your method, so the backtrace would contain a frame between frames 0 and 1. The fact that there’s no frame there implies that this might be compiler-generated preamble or postamble code but, honestly, there’s a bunch of other possibilities.

If I were in this situation I’d disassemble

DiscoverViewController.tableView(_:cellForRowAt:)
and see how you can get to the code at offset 1732, but that’s not something for the faint hearted.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Do you know what's SEGV_ACCERR selected (<compiler-generated>:) mean? I got crash for SEGV_ACCERR selected (<compiler-generated>:). Wait for your responSe.