When symbolicating an app built with Xcode 7.0 (7A220) (and on a system where Xcode 7 is the selected version of Xcode for command line tools), symbolication fails with:

Interestingly, if I build MacSymbolicator from source, symbolication simply hangs. Running symbolicate.rb directly, the xcrun atos command seems to be the culprit.

Not sure if this is a bug in Xcode 7.0, or a non-bug change that requires an update to the symbolication script...

I'm going to keep digging in, but this is mostly new territory for me.

When symbolicating a crash log (ips) the section at the top of a crash with "Application Specific Backtrace" does not get symbolicated:

Application Specific Backtrace 0:
0   CoreFoundation                      0x00007ff810a1c7c3 __exceptionPreprocess + 242
1   libobjc.A.dylib                     0x00007ff81077cbc3 objc_exception_throw + 48
2   Foundation                          0x00007ff81185f3bb -[NSUndoManager _prepareEventGrouping] + 0
3   libswiftFoundation.dylib            0x00007ff82212812f $sSo13NSUndoManagerC10FoundationE12registerUndo10withTarget7handleryx_yxctRlzClF + 207
4   MyAppName                           0x0000000104404d45 MyAppName + 4803909
5   MyAppName                           0x000000010417da08 MyAppName + 2152968
6   MyAppName                           0x000000010408af57 MyAppName + 1158999
7   MyAppName                           0x0000000104083745 MyAppName + 1128261
8   MyAppName                           0x00000001041d56c0 MyAppName + 2512576
9   MyAppName                           0x00000001045556d1 MyAppName + 6182609
10  MyAppName                           0x000000010425e579 MyAppName + 3073401
11  libdispatch.dylib                   0x00007ff8107220cc _dispatch_call_block_and_release + 12
12  libdispatch.dylib                   0x00007ff810723317 _dispatch_client_callout + 8
13  libdispatch.dylib                   0x00007ff810729317 _dispatch_lane_serial_drain + 672
14  libdispatch.dylib                   0x00007ff810729dfd _dispatch_lane_invoke + 366
15  libdispatch.dylib                   0x00007ff810733eee _dispatch_workloop_worker_thread + 753
16  libsystem_pthread.dylib             0x00007ff8108d6fd0 _pthread_wqthread + 326
17  libsystem_pthread.dylib             0x00007ff8108d5f57 start_wqthread + 15

Note the second name in the line with the Application name. When this is changed manually to the load address for the app the symbolication works as expected.

Does NOT work:

4 MyAppName 0x0000000104404d45 MyAppName + 4803909

Does work:

4 MyAppName 0x0000000104404d45 0x0000123 + 4803909

the download link is broken

https://tars.mahdi.jp/MacSymbolicator/Sparkle/MacSymbolicator-latest.zip

where can we get it? ;)

when I run it in debug mode, print in console:

2020-06-24 10:07:39.573144+0800 MacSymbolicator[44885:2521825] Metal API Validation Enabled
2020-06-24 10:07:39.593602+0800 MacSymbolicator[44885:2522201] flock failed to lock maps file: errno = 35
2020-06-24 10:07:39.593941+0800 MacSymbolicator[44885:2522201] flock failed to lock maps file: errno = 35
2020-06-24 10:07:39.673260+0800 MacSymbolicator[44885:2521825] [logging-persist] cannot open file at line 43353 of [378230ae7f]
2020-06-24 10:07:39.673301+0800 MacSymbolicator[44885:2521825] [logging-persist] os_unix.c:43353: (0) open(/var/db/DetachedSignatures) - Undefined error: 0

after I import crash file and then symbolicate it, nothing happened

System: OSX Catalina 10.15.3
xcode: 11.5

n/t

Here is the log I am attempting to debug. I copy/pasted it from a modal that was the result of a mysterious install-time crash I have been trying to fix.

log.crash.txt

It is clearly not symbolicated but the app reports that it is.

Trying to proceed anyway just results in an empty output

I archive my dSYMs in folders that are named like this:

 dSYM 2.4 (352.0)

When I use the app or the CLI and pass a path to that folder with a dSYM inside, it silently fails. If I rename the folder to not include spaces nor parens, it works.

ruby symbolicate.rb <crash_file> <dsym_file>

after ~20min - Couldn't continue because of atos error.

DSYM - 32mb

A script using the CLI will generally need the image names and UUIDs so it can locate the dsym bundle(s) it needs to pass to the CLI.

This is particularly important as the CLI edition doesn't search for them.

Is_ that necessary if the .crash file can be pulled in XCode 13.1 via Device Simulator.
In other words, you don't need a second tool for the same work.
Where's the progress now?

There seem to be some changes on MacOs Ventura, that MacSymbolicator does not work. Does not seem to accept .dSym files. Either drag and drop is broken on that half - as i am able to add .ips crash file.

might be related to this issue - getsentry/apple-system-symbols-upload#5

I am running MacSymbolicator 2.3 (5)

When analyzing a crash report it symbolicates items from a thread, but misses items in main backtrace (items "Astro Gold"). My best guess as to why this happens is some problem with regex matching causing the entries in the main backtrace to be missed.

This is the log generated by the app:

Searching Spotlight for UUIDs: ["F6CBD55D-BEF2-3C06-9950-9B36D48695C4"]
Found F6CBD55D-BEF2-3C06-9950-9B36D48695C4: /Users/gpdawson/Library/Developer/Xcode/Archives/2021-10-06/Astro Gold 6-10-21, 8.43 am.xcarchive/dSYMs/Astro Gold.app.dSYM
Running command: xcrun atos -o "/Users/gpdawson/Library/Developer/Xcode/Archives/2021-10-06/Astro Gold 6-10-21, 8.43 am.xcarchive/dSYMs/Astro Gold.app.dSYM/Contents/Resources/DWARF/Astro Gold" -arch x86_64 -l 0x100a49000 0x0000000100c74d2a 0x0000000100c76b13
STDOUT: FIRCLSSDKFileLog (in Astro Gold) (FIRCLSInternalLogging.c:0)
FIRCLSMachExceptionServer (in Astro Gold) (FIRCLSMachException.c:170)
STDERR:
Replacing matches in sample report: []
Replacing matches in crash report: ["0x0000000100c74d2a 0x100a49000 + 2276650"]
Replacing matches in sample report: []
Replacing matches in crash report: ["0x0000000100c76b13 0x100a49000 + 2284307"]

Two relevant extracts from crash file are as follow.

Application Specific Information:
Crashing on exception: *** -[__NSArrayM objectAtIndex:]: index 14 beyond bounds [0 .. 12]

Application Specific Backtrace 1:
0 CoreFoundation 0x00007fff420bff3b __exceptionPreprocess + 171
1 libobjc.A.dylib 0x00007fff69418942 objc_exception_throw + 48
2 CoreFoundation 0x00007fff420fffcc _CFThrowFormattedException + 194
3 CoreFoundation 0x00007fff41fe1faf -[__NSArrayM objectAtIndex:] + 175
4 Astro Gold 0x0000000100b74ad0 Astro Gold + 1227472
5 Astro Gold 0x0000000100a942cb Astro Gold + 307915
6 AppKit 0x00007fff3fe75f29 _NSViewDrawRect + 83
7 AppKit 0x00007fff3fe831c4 -[NSView(NSInternal)

Thread 2:: com.google.firebase.crashlytics.MachExceptionServer
0 libsystem_kernel.dylib 0x00007fff6a1856fa write + 10
1 com.ajnaware.Astro-Gold 0x0000000100c74d2a 0x100a49000 + 2276650
2 com.ajnaware.Astro-Gold 0x0000000100c76b13 0x100a49000 + 2284307
3 libsystem_pthread.dylib 0x00007fff6a34b661 _pthread_body + 340
4 libsystem_pthread.dylib 0x00007fff6a34b50d _pthread_start + 377
5 libsystem_pthread.dylib 0x00007fff6a34abf9 thread_start + 13

In version 1.1 it would automatically save the symbolicated crash in the directory from where the unsymbolicated was dragged. This allowed XCode when restarted to display the symbolicated crashes.

There should probably be an option to delete the unsymbolicated version.

Also, it used to automatically symbolicate when the source was dragged - now you need to click the symbolicate button.

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

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

Invaluable tool and love the fact that you have added support for Sample reports too. I have a suggestion to improve the workflow even more. For non-App Store apps, it is common that a crash report will be attached to a bug reporting or customer care system (as in the case for SuperDuper!) that the developer will download to ~/Downloads for analysis. Currently the dSym search is limited to the location of the crash report file itself or a hard-coded Xcode archive path. In my particular use case, neither works because I download the crash reports to ~/Downloads and my Xcode archives are located in ~/Projects/Archives.

That said, Spotlight indexes all Xcode .dSym files on the system providing an extremely fast way to locate a dSym file for a given uuid. For example, mdfind "com_apple_xcode_dsym_uuids == 50D5553D-FA9A-2541-272F-7C6F43916630" will quickly return the dSym location for 50D5553D-FA9A-2541-272F-7C6F43916630. You can even find all dSym files on the system using mdfind "com_apple_xcode_dsym_uuids == *" as an intelligent enumeration set. I'de suggest that the file search should be extended to intelligently short-circuit the dSym search by using Spotlight first or at least by adding it between the peer-to-crash-report check and the hard-coded Xcode archive enumeration search (this Xcode Archive path should also be a preference).

Thanks for taking the time to develop such an invaluable tool and making it available to the broader community.

For some reason the spotlight search (NSMetadataQuery) isn't finding a .DSYM that is in my desktop directory automatically. I know the UUID is correct because running the mdfind command in terminal has no problem.

I was looking through historical issues related to "com_apple_xcode_dsym_uuids" and I'm wondering if this isn't working as expected again. #16

My machine is running macOS Sonoma 14.2.1 (23C71)

user@directory % mdfind "com_apple_xcode_dsym_uuids == E3D58A29-035A-37E5-A5FD-01C818692997"
/Users/user/Desktop/DSYMS/AppName.app.dSYM

Trying to force the app to search for it in the symbolicate button yields no results. From Xcode Version 15.2 (15C500b)

    @objc func symbolicate() {
        spotlight.search(forUUIDs: ["E3D58A29-035A-37E5-A5FD-01C818692997"]) { result in
            print(result)
        }

--> Optional([])

Thoughts on having a settings option the user can turn on to run the mdfind command in a Process if the spotlight search came up empty?

From the same project, this works:

    @objc func symbolicate() {
        let command = "mdfind \"com_apple_xcode_dsym_uuids == E3D58A29-035A-37E5-A5FD-01C818692997\""
        let result = command.run()
        print(result.output ?? "no results")

--> /Users/user/Desktop/DSYMS/AppName.app.dSYM

Thank you very much for this tool! It's much simpler to use than manually symbolicating each frame by hand!

I'm having an issue when trying to use a bundled DSYM file. My application has multiple targets where each generate their own DSYM that is bundled in a "master" DSYM. When I try and symbolicate a crash, MacSymbolicator does replace the symbols for the main target (application), but not for the embedded frameworks.

I've tried manually using the DSYMs for each target, but the app shows a warning saying UUID mismatch (which makes sense since this DSYM wouldn't have the same UUID as the main application.

It seems to me MacSymbolicator should also try and match the DSYM's UUID against the Embedded Binaries section in the crash log.

First of all - app is amazing and is one of a kind! Now, the issue is - on new version of Mac OS - Monterey they decided to change extension and format of crash logs. Is it possible to add handling of new syntax?

We have built automation to run monkey tests for 10min+ and our app crashing because of:

• 1073.76 MB of file backed memory dirtied over 3789 seconds (283.42 KB per second average), exceeding limit of 12.43 KB per second over 86400 seconds
• 90 seconds cpu time over 112 seconds (80% cpu average), exceeding limit of 50% cpu over 180 seconds

But when I tried to symbolicate these .ips files, app writes me Unexpected format.

reports.zip

If I try to symbolicate a macOS crash report in ips format, it fails with the error message "Unexpected format" and with the following line in the log file:

Error loading report file: translation(MacSymbolicator.Translator.Error.couldNotFindClass)

If need be I can provide an example of a failing ips crash report. I'm running macOS 10.14.6 in case that matters.

I think it should be easy to add support ips, mostly need change filter in UI

I have a crash file that does symbolicate correctly in v2.3 but failed with the following error when i use either v2.4 or v2.5

Error loading report file: translation(MacSymbolicator.Translator.Error.unexpectedOutput)

I could not be able to share the crashlog, but let me know if anything I could do to help in getting additional debug info

What format does the customized crash log need to be parsed

Initial setup fails with:

 % carthage bootstrap --platform osx 
*** Checking out Mantle at "1.5.8"
*** Checking out ReactiveCocoa at "v2.5"
*** Checking out Squirrel.Mac at "0.3.2"
*** xcodebuild output can be found in /var/folders/98/ygdvwj1j075ccgqn9br5yszc0000gn/T/carthage-xcodebuild.TEdn7z.log
*** Downloading ReactiveCocoa.framework binary at "v2.5"
*** Downloading Squirrel.Mac.framework binary at "0.3.2"
*** Building scheme "Mantle Mac" in Mantle.xcworkspace
Failed to write to /Users/USERNAME/src/MacSymbolicator-master/Carthage/Build/Mac/Mantle.framework: Error Domain=NSCocoaErrorDomain Code=260 "The file “Mantle.framework” couldn’t be opened because there is no such file." UserInfo={NSURL=file:///Users/USERNAME/src/MacSymbolicator-master/Carthage/Checkouts/Mantle/build/ArchiveIntermediates/Mantle%20Mac/BuildProductsPath/Release/Mantle.framework, NSFilePath=/Users/USERNAME/src/MacSymbolicator-master/Carthage/Checkouts/Mantle/build/ArchiveIntermediates/Mantle Mac/BuildProductsPath/Release/Mantle.framework, NSUnderlyingError=0x7fa8d7f1d830 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}

 % carthage version 
0.34.0

For ips:

Thread 0::  Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	       0x19df63750 __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x19dfa0574 _pthread_cond_wait + 1232
2   libc++.1.dylib                	       0x19dec8ef0 std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28
3   bdlli-bind                    	       0x10507c1ac llvm::ThreadPool::wait() + 60
4   bdlli-bind                    	       0x104f48f04 main + 4028
5   dyld                          	       0x19dc47f28 start + 2236

This regex parsing the line into the wrong status:

• system symbol (the __psynch_cvwait)

• app symbol (the llvm::ThreadPool::wait())

This code does not match what it actually get. The component[0] is not target at all

I think this is a bug similiar to #35

I saw the Tests and found a issue.

in original crash,

in symbolicated crash,

I am wondering if there is a issue when replacing regex.

because the appcast feed
http://dl.dropboxusercontent.com/u/2439981/MacSymbolicator/Sparkle/appcast.xml
is offline

Right now, spin dump files are not recognized although they are pretty similar to crash dumps. There are actually only are few changes necessary in CrashFile.swift to support them:

To parse the architecture:

// Spin dumps have the architecture in the "Architecture:" field.
if self.architecture?.isIncomplete ?? true {
    self.architecture = (content.scan(pattern: "^Architecture:\\s+(\\S+)\\s*$").first?.first
        .flatMap(Architecture.init))
}

(BTW, I think self.architecture?.isIncomplete == true is wrong for the ARM test as well; if the architecture string was not parsed self.architecture is nil.)

An unresolved spin dump line looks like this:

1000  ??? (Foo + 4304068) [0x104557cc4]

You can get those via:

let spinDumpAddresses = content.scan(
    pattern: "^\\s*\\d+\\s+\\?{3}\\s+\\(.*?\\+.*?\\)\\s+\\[(0x.*?)\\]"
).compactMap { $0.last }

self.addresses = crashReportAddresses + sampleAddresses + spinDumpAddresses

A spin dump can contain quite a lot of entries, a lot more than a regular crash dump (one I've got at hand right now has about 1700 in total, with about 800 unresolved). There are often addresses in some system libraries that start with 0xff… or 0x7f…, filtering those out (after lowercasing the address in compactMap) speeds up the symbolication as in my case, of the ~800 unresolved symbols "only" ~600 were left to be resolved after this filtering.

    .filter { !$0.hasPrefix("0xff") && !$0.hasPrefix("0x7f") }

a new square icon would be great, and give MacSybolicator a little more polish.
If you have the source files for the current icon, id be happy to create an updated design