Add support for spin dumps

[DarkDust]

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") }

[inket]

Hi! Thank you for the details.

I played a bit with spindumps and I found that the spindump command will actually allow you to symbolicate spindumps! - provided the file includes the binary format. I'd rather use that as a first-choice to symbolicate than atos since it seems to recognize system libraries by itself.

Currently the app is built with the assumption that a crash file will have one UUID but in the case of a spindump file it might have many UUIDs. I'm thinking I will have to change the logic to do this:

• Accept any file (.txt or .crash)
• Check for UUIDs in that file:
  • If one:
    • Search for DSYM using that UUID
    • Use spindump -i file.txt -dsym <dsym> which will symbolicate it if it's a spindump with a binary format
    • Use atos to symbolicate the remaining symbols
  • If many (spindumps without -onlyTarget):
    • Ask user to provide the DSYM manually
    • Use spindump -i file.txt -dsym <dsym> which will symbolicate it if it's a spindump with a binary format
    • Use atos to symbolicate the remaining symbols matching the DSYM UUIDs

An additional improvement to the app's logic to make it recognize the binary images in the crash reports and spin dumps would also allow for:

• Symbolicating only the necessary symbols without needing to filter addresses starting with 0xff/0x7f
• Avoiding scanning for "Architecture" since we can get it from the DSYM file using dwarfdump

Thanks for the help. This will be a lot of work but it's worth it! I will probably have it released before the end of April so stay tuned.

[siracusa]

Any progress on this? I would love to be able to symbolicate the spindump text files produced by my beta testers using the Activity Monitor app.

[inket]

The new version (2.5) adds support for symbolicating spindump reports!

I decided to go with a different approach than what I described earlier: Since spindump reports on many processes, I figured a potential use-case is reporting on an app that has many processes. In which case, just symbolicating the first process in the report is not enough. With the new version, MacSymbolicator will parse the whole report, and detect all the processes (user and system). It will symbolicate all the processes that you provide dSYMs for.

I hope this works well. If you find any issues or edge cases, please tell me. (feel free to create a new issue)

[siracusa]

Works great, thanks!