Interpreting crash log assertionFailure

Hello, I am experiencing crash on TopShelf and I checked all the crashlogs, but I don't know how to interpret it.

I see only addresses in the trace logs, so it's really hard to understand what's going on. Is there a way how to symbolicate frames 5 - 17?

Does anybody have an idea, what can be wrong?

Thanks in advance.

0   libswiftCore.dylib            	0x000000019bd33a88 _assertionFailure(_:_:file:line:flags:) + 264 (AssertCommon.swift:147)
1   TopShelf                      	0x00000001048b998c 0x1045ac000 + 3201420
2   TopShelf                      	0x0000000104cc04a8 0x1045ac000 + 7423144
3   libdispatch.dylib             	0x000000019ab89294 _dispatch_client_callout + 20 (object.m:576)
4   libdispatch.dylib             	0x000000019ab8aae0 _dispatch_once_callout + 32 (once.c:52)
5   TopShelf                      	0x00000001048f4098 0x1045ac000 + 3440792
6   TopShelf                      	0x00000001048f4930 0x1045ac000 + 3442992
7   TopShelf                      	0x00000001048cc8bc 0x1045ac000 + 3279036
8   TopShelf                      	0x00000001045b5a61 0x1045ac000 + 39521
9   TopShelf                      	0x0000000104ca8841 0x1045ac000 + 7325761
10  TopShelf                      	0x00000001049e5cc5 0x1045ac000 + 4431045
11  TopShelf                      	0x0000000104cc0dfd 0x1045ac000 + 7425533
12  TopShelf                      	0x00000001045b4b95 0x1045ac000 + 35733
13  TopShelf                      	0x00000001045b4e81 0x1045ac000 + 36481
14  TopShelf                      	0x00000001045b50e5 0x1045ac000 + 37093
15  TopShelf                      	0x00000001045b5a61 0x1045ac000 + 39521
16  TopShelf                      	0x00000001045b54b5 0x1045ac000 + 38069
17  TopShelf                      	0x00000001045b50e5 0x1045ac000 + 37093
18  libswift_Concurrency.dylib    	0x000000019c30aedd completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1 (Task.cpp:497)
Answered by DTS Engineer in 832121022

Ah, so TopShelf is the name of your app (well, appex). That was a key point of confusion for me.

I apologize for partially symbolicated crash report.

Symbolicating that crash report is key to fixing this. Consider the crashing thread backtrace:

Thread 6 Crashed:
0   libswiftCore.dylib         … _assertionFailure(_:_:file:line:flags:) + 264 (AssertCommon.swift:147)
1   TopShelf                   … 0x100b4c000 + 3185020
2   TopShelf                   … 0x100b4c000 + 7397752
3   libdispatch.dylib          … _dispatch_client_callout + 20 (object.m:576)
4   libdispatch.dylib          … _dispatch_once_callout + 32 (once.c:52)
5   TopShelf                   … 0x100b4c000 + 3424052
…
17  TopShelf                   … 0x100b4c000 + 20709
18  libswift_Concurrency.dylib … completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1 (Task.cpp:497)

Frame 18 shows that this code is being called by the Swift concurrency runtime. Frames 17 through through 5 are your code. Frames 4 and 3 indicate that you’re initialising some sort of global using the dispatch_once mechanism. Frames 2 through 0 are the code that’s run by this mechanism. Frame 1 is the most critical, because it’s tripped the assert that’s caused this trap.

So, you really need to symbolicate the crash report to uncover the identity of frames 1, 2, and 5. See Adding identifiable symbol names to a crash report for instructions on how to do that.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Can you post the full crash report? See Posting a Crash Report for advice on how to do that.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you for your response. I attached the file.

I can not reproduce the crash, this is crash report from users I found it in Organizer, so I apologize for partially symbolicated crash report.

Reading all the crash logs I noticed that crashed thread is always > 0

For this example, it's Thread 6

Thread 6 Crashed:
0   libswiftCore.dylib            	0x000000018e0a3a88 _assertionFailure(_:_:file:line:flags:) + 264 (AssertCommon.swift:147)
1   TopShelf                      	0x0000000100e5597c 0x100b4c000 + 3185020
2   TopShelf                      	0x000000010125a178 0x100b4c000 + 7397752
3   libdispatch.dylib             	0x000000018cef9294 _dispatch_client_callout + 20 (object.m:576)
4   libdispatch.dylib             	0x000000018cefaae0 _dispatch_once_callout + 32 (once.c:52)
5   TopShelf                      	0x0000000100e8ff34 0x100b4c000 + 3424052
6   TopShelf                      	0x0000000100e907cc 0x100b4c000 + 3426252
7   TopShelf                      	0x0000000100e68968 0x100b4c000 + 3262824
8   TopShelf                      	0x0000000100b51a61 0x100b4c000 + 23137
9   TopShelf                      	0x0000000101242511 0x100b4c000 + 7300369
10  TopShelf                      	0x0000000100f81ab5 0x100b4c000 + 4414133
11  TopShelf                      	0x000000010125aacd 0x100b4c000 + 7400141
12  TopShelf                      	0x0000000100b50b95 0x100b4c000 + 19349
13  TopShelf                      	0x0000000100b50e81 0x100b4c000 + 20097
14  TopShelf                      	0x0000000100b510e5 0x100b4c000 + 20709
15  TopShelf                      	0x0000000100b51a61 0x100b4c000 + 23137
16  TopShelf                      	0x0000000100b514b5 0x100b4c000 + 21685
17  TopShelf                      	0x0000000100b510e5 0x100b4c000 + 20709
18  libswift_Concurrency.dylib    	0x000000018e67aedd completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1 (Task.cpp:497)

Ah, so TopShelf is the name of your app (well, appex). That was a key point of confusion for me.

I apologize for partially symbolicated crash report.

Symbolicating that crash report is key to fixing this. Consider the crashing thread backtrace:

Thread 6 Crashed:
0   libswiftCore.dylib         … _assertionFailure(_:_:file:line:flags:) + 264 (AssertCommon.swift:147)
1   TopShelf                   … 0x100b4c000 + 3185020
2   TopShelf                   … 0x100b4c000 + 7397752
3   libdispatch.dylib          … _dispatch_client_callout + 20 (object.m:576)
4   libdispatch.dylib          … _dispatch_once_callout + 32 (once.c:52)
5   TopShelf                   … 0x100b4c000 + 3424052
…
17  TopShelf                   … 0x100b4c000 + 20709
18  libswift_Concurrency.dylib … completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1 (Task.cpp:497)

Frame 18 shows that this code is being called by the Swift concurrency runtime. Frames 17 through through 5 are your code. Frames 4 and 3 indicate that you’re initialising some sort of global using the dispatch_once mechanism. Frames 2 through 0 are the code that’s run by this mechanism. Frame 1 is the most critical, because it’s tripped the assert that’s caused this trap.

So, you really need to symbolicate the crash report to uncover the identity of frames 1, 2, and 5. See Adding identifiable symbol names to a crash report for instructions on how to do that.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I greatly appreciate your response.

I was able to symbolicate it.

Thread 6 Crashed:
0   libswiftCore.dylib            	0x000000018e0a3a88 _assertionFailure(_:_:file:line:flags:) + 264 (AssertCommon.swift:147)
1   TopShelf                      	0x0000000100e5597c specialized static ContextMenuMetadata.__derived_struct_equals(_:_:) (in TopShelf) (/<compiler-generated>:0)
2   TopShelf                      	0x000000010125a178 one-time initialization function for FT_Proto_Common_V3_Custom_SchemaDescription_Extensions (in TopShelf) (schema_description.pb.swift:116)
3   libdispatch.dylib             	0x000000018cef9294 _dispatch_client_callout + 20 (object.m:576)
4   libdispatch.dylib             	0x000000018cefaae0 _dispatch_once_callout + 32 (once.c:52)
5   TopShelf                      	0x0000000100e8ff34 FTPlayer.convert(_:) (in TopShelf) (PlaybackDetails.swift:106)
6   TopShelf                      	0x0000000100e907cc initializeBufferWithCopyOfBuffer for PlaybackDetails (in TopShelf) (/<compiler-generated>:0)
7   TopShelf                      	0x0000000100e68968 assignWithCopy for GuidePage (in TopShelf) (/<compiler-generated>:0)
8   TopShelf                      	0x0000000100b51a61 initializeWithCopy for MarqueeTextView (in TopShelf) (/<compiler-generated>:0)
9   TopShelf                      	0x0000000101242511 JSONSafeEncoder.__deallocating_deinit (in TopShelf) (JSONSafeEncoder.swift:34)
10  TopShelf                      	0x0000000100f81ab5 type metadata completion function for FTButtonIcon (in TopShelf) (/<compiler-generated>:0)
11  TopShelf                      	0x000000010125aacd <deduplicated_symbol> (in TopShelf) + 5
12  TopShelf                      	0x0000000100b50b95 closure #1 in MarqueeTextView.plainText(stringWidth:size:) (in TopShelf) (/<compiler-generated>:0)
13  TopShelf                      	0x0000000100b50e81 MarqueeTextView.scrollableTextView.getter (in TopShelf) (MarqueeTextView.swift:96)
14  TopShelf                      	0x0000000100b510e5 closure #1 in MarqueeTextView.scrollableText(stringWidth:size:) (in TopShelf) (MarqueeTextView.swift:113)
15  TopShelf                      	0x0000000100b51a61 initializeWithCopy for MarqueeTextView (in TopShelf) (/<compiler-generated>:
16  TopShelf                      	0x0000000100b514b5 closure #3 in MarqueeTextView.scrollableText(stringWidth:size:) (in TopShelf) (MarqueeTextView.swift:131)
17  TopShelf                      	0x0000000100b510e5 closure #1 in MarqueeTextView.scrollableText(stringWidth:size:) (in TopShelf) (MarqueeTextView.swift:113)
18  libswift_Concurrency.dylib    	0x000000018e67aedd completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1 (Task.cpp:497)

Analyzing these crash logs raises several additional questions. TopShelf is appex for tvOS top shelf, but the trace shows the code for the main application. Does this imply that when a user opens an application through the top shelf, the TopShelf appex is also utilized, even when the user is currently within the main application? This suggests that the crash may not necessarily be occurring within the TopShelf application but rather within the main application itself.

I was able to symbolicate it.

Yay!

Does this imply that when a user opens an application through the top shelf, the TopShelf appex is also utilized, even when the user is currently within the main application?

No. Apps and their app extensions aren’t intermingled like this.

I suspect that your have some sort of unexpected code path within your appex that’s causing it to end up running this code.

One way of thinking about this is If the appex can’t run this code, why is the code in the appex at all? Try removing the code from the appex entirely. As you do that, you’ll find all the places where the appex depends on it, and that might offer some insight into how it’s being run.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Interpreting crash log assertionFailure
 
 
Q