Exception SIGABRT encountered in App Store review

The crash log shows the exception type as SIGABRT and documentation. indicates that the crash may arise from an uncaught exception.

Probably. Technically SIGABRT just means that some code within the process called abort, but the most common cause of that is an unhandled language exception.

Beyond that it’s hard to say what’s going on here based on the crash report snippet you posted. 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"

Full crash log attached:

Thanks for the crash report.

And I’m glad I asked for it because I was able to use it to better symbolicate your log. Your crash report shows frame 2 as:

2 CoreFoundation … -[__NSArrayM copyWithZone:] + 0

The offset of 0 was hard to explain, but when I symbolicate it myself I get this:

2 CoreFoundation … -[__NSSingleObjectArrayI objectAtIndex:] + 140 …

That makes a lot more sense. And this exception is almost certainly triggered by an array out of bounds.

So, to recap, the backtrace of the exception is this:

0   CoreFoundation  … __exceptionPreprocess + 240 …
1   libobjc.A.dylib … objc_exception_throw + 60 …
2   CoreFoundation  … -[__NSSingleObjectArrayI objectAtIndex:] + 140 …
3   Caption Pro     … Caption Pro + 105336
4   Caption Pro     … Caption Pro + 101464
5   Caption Pro     … Caption Pro + 100128
6   CoreFoundation  … -[NSSet makeObjectsPerformSelector:] + 216 …
7   AppKit          … -[NSIBObjectData nibInstantiateWithOwner:options:topLevelObjects:] + 1080 …
8   AppKit          … loadNib + 416 …
9   AppKit          … +[NSBundle(NSNibLoading) _loadNibFile:nameTable:options:withZone:ownerBundle:] + 800 …
10  AppKit          … -[NSBundle(NSNibLoading) loadNibNamed:owner:topLevelObjects:] + 220 …
11  AppKit          … +[NSBundle(NSNibLoading) loadNibNamed:owner:] + 388 …
12  AppKit          … NSApplicationMain + 576 …
13  dyld            … start + 520 …

Frames 12 through 6 are AppKit loading your main nib. That enters your code at frame 5 which eventually triggers an exception by accessing an array element out of bounds at frame 2.

To make progress on this you need to identify the code that did that, and that means symbolicating your frames in that backtrace (frame 5 through 3). For instructions on how to do this, see Adding Identifiable Symbol Names to a Crash Report.

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

Thanks for all the effort you've put in to deal with this problem. Have you any idea why I can't reproduce it on my MacOS 12.4 machine? I may be writing to a log file outside the sandbox but I don't think it would cause the observed crash. I've tried running the app in a fresh account (using the distribute to development team archive option) on the dev Mac but it doesn't crash. A non-reproducible problem I'm having is that sometimes the app menu bar is unresponsive - sub-menus are only visible when the touchpad is pressed. The app then has to be stopped from Xcode or killed using Activity Monitor. Sometimes windows shown do not respond to the close button. Could these be connected with the crash which the app reviewer encountered?

Have you any idea why I can't reproduce it on my MacOS 12.4 machine?

Sometimes bugs can be hard to reproduce. People joke about “phase of the moon” bugs but in my DTS career I’ve helped developers fix bugs that were literally dependent on the phase of the moon (-:

My advice is that your symbolicate your crash report because the identity of the code in frames 5 through 3 should give you a hint as to how this has come about. And that might be enough to fix the bug, or at least give you a clue as to how to reproduce it.

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

I'm not able to further symbolicate the crash report from App Review as there is no Download Debug Symbols button shown in the Archive Organiser (shown in Xcode 13 with Window->Organiser) for the build which failed. I tried resubmitting and got the same result, only App Review has now moved to MacOS 12.5 and i have MacOS 12.4.

there is no Download Debug Symbols button

You shouldn’t need to download debug symbols. Consider this quote from the Download debug symbols page in Xcode help:

If you include bitcode when you upload your app to App Store Connect

Downloading debug symbols is only relevant if you use bitcode, and there’s no point using bitcode in a Mac App Store app [1].

So:

• Make sure you’re not using bitcode.

• Symbolicate using the .dSYM files created by your local build.

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

[1] As of WWWDC this year, bitcode is effectively deprecated for all our platforms, but it’s never been relevant to Mac App Store apps.

When I followed the procedure to symbolicate an external file by changing the .ips extension to .crash, adding an external device, viewing All Logs and dragging the .crash file from MacOS12.4 Finder to the LH column, a part of the log appear in the RH window but does not include any frame data. The last line is Crashed Thread: 0 Dispatch queue enabled. Right-clicking on the added file and selecting Re-Symbolicate Log results in nothing happening. If I click Done and open View All Logs again, the added file is not present. I presumed this was due to lack of debug symbols but from your comment this is not the case.

I presumed this was due to lack of debug symbols

The thing is, the info in Adding Identifiable Symbol Names to a Crash Report let’s you test that presumption:

1. Get the code’s UUID from the Binary Images section of the log.

2. Use dwarfdump to confirm that you have a .dSYM file with the right UUID.

3. Use mdfind to confirm that it’s visible to the symbolicator.

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

Do you think the reason I am unable to further symbolicate the .ips file is because I do not have the correct .dSym file?

The Binary Images section of the .ips file is as shown below. Where is the required UUID?

Can you tell me how to use dwarfdump to see if I have a .dSYM with the right UUID and how to use mdfind to see if it is visible to the symbolicator and what to do if it is not?

Do you think the reason I am unable to further symbolicate the .ips file is because I do not have the correct .dSym file?

I don’t know, but this is one of the most common causes of such problems.

Can you tell me how to use dwarfdump to see if I have a .dSYM with the right UUID and how to use mdfind to see if it is visible to the symbolicator and what to do if it is not?

That information is in Adding Identifiable Symbol Names to a Crash Report. Open that page and search for dwarfdump for the first and mdfind for the second.

Where is the required UUID?

If you look in the above-mentioned doc, there’s an image that illustrates this in the discussion of mdfind.

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

Hi Quinn

I've had no success in following the symbolication instructions - mdfind does not find anything using the UUID in the frames containing the words Caption Pro.

I tried creating an out-of-bounds array access to trigger an exception and the crash log indicated that this was the problem. On checking my log file, there seems to be no possibility of an out-of-bounds array access before the crash occurs, so the origin of SIGABRT is still unclear. I have added a lot more logging, including the created array item count and will resubmit in the hope of getting more detailed info on where the crash occurs. I have packaged the app for distribution to customers and asked a couple of Mac friends to see if they can run it on up-to-date machines. One of them has done so successfully, so the problem the App Reviewer has is still mysterious

The error found by App Review was indeed an out-of-bounds array access caused by my reading CFBundleVersion as the app version rather than CFBundleShortVersionString. CFBundleVersion is actually the build version. I had set this to the app version (3.1.25) and all users except the App store reviewers read this sucessfully and split the version number into components at the ., but the App Store review environment seems to replace whatever you put in the field with the number of times you've submitted to the App Store. so the value was a single integer, which could not be split at '.'. This is why I could never reproduce the crash. I never succeeded in symbolicating the crash logs from App review in Xcode and have raised a separate query about that. Thanks for your help - maybe it will help avoid more frustration for Mac developers