Couldn't continue because of atos error.

[peterpaulis]

The dSym is good, the crash too, but still getting

Couldn't continue because of atos error.
[link redacted]

[inket]

Hi, thank you for the report. I will take a look at it.

(btw, I redacted the link from your post to remove the dsym link [should be kept secret!])

[peterpaulis]

not sure about the error, but maybe a display of the error encountered would help :)

[demitri]

I ran into this issue. The problem is in the "Code Type" line. This is taken from a crash report that was very recently generated:

Code Type:             X86-64 (Native)

MacSymbolicator isn’t expecting the "(Native)" string. You can see this if you download the program, build it in Xcode, and symbolicate from there:

sh: -c: line 0: syntax error near unexpected token `('
sh: -c: line 0: `xcrun atos -o "<path>/Contents/Resources/DWARF/<app>" -arch X86-64 (Native) -l 0x10fac4000 0x00000001101c2d25 0x00000001101bcf1e 0x00000001101bbb08 0x000000011016acf8 0x00000001101ba4f0 0x00000001101b0baf 0x00000001101b01f1 0x00000001101a8f74 0x000000011002ed8a 0x000000010fda03a3'

You can see the parameter to -arch is X86-64 (Native) instead of X86-64. Remove the "(Native)" from your crash report and it will run.

I'd submit a patch to check for this and parse it properly, but don't know Ruby.

[sweetppro]

@demitri I submitted a pull request based on your findings
:)

[demitri]

@sweetppro Fantastic - thanks! Does this fix support both the "original" format and the "new" one with the extra text? Presumably this will be seen from different versions of macOS.

[inket]

Fixing the code type parsing should prevent the atos error from appearing. Thank you for noticing that.

---

However, some crash reports will still have zero new information when symbolicated. In OP's case, the crash report he shared (redacted for privacy) might indicate a problem loading the app binary. Here's a snippet:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   ???                           	0x000000010749bdeb 0 + 4417240555
1   ???                           	0x00000001074953a9 0 + 4417213353
2   ???                           	0x0000000107494470 0 + 4417209456
3   ???                           	0x000000010753b7f3 0 + 4417894387
4   ???                           	0x000000010753b087 0 + 4417892487
5   ???                           	0x000000010753ac23 0 + 4417891363
6   ???                           	0x000000010746f293 0 + 4417057427
7   ???                           	0x000000010747308c 0 + 4417073292
8   ???                           	0x00000001074721db 0 + 4417069531
9   ???                           	0x000000010749e91d 0 + 4417251613
10  ???                           	0x00000001074714b0 0 + 4417066160
11  ???                           	0x0000000107470502 0 + 4417062146
12  ???                           	0x000000010745f2d8 0 + 4416991960
13  com.apple.Foundation          	0x00007fff83f8c6d5 -[NSBlockOperation main] + 75

Notice that instead of showing the app name in the call stack, it only showed ???. The load address of the app binary is 0xffffffffffffffff

Binary Images:
                 0 - 0xffffffffffffffff +com.someapp.appname (1.4.0 - 58) 

If anyone has an idea of what might be causing this, that would be a huge help.

[martinhering]

Sound like the same issue, I had. Fixed that for me.

Try my fork:
https://github.com/martinhering/MacSymbolicator