Kscrash: AppleFormatReport binary Images arch is wrong?

I think I have the same problem. I wonder if there is a way to fix this?

@kstenerud Hello, I wonder if you know a way to fix this? If you give me some pointers or a place to start to look at I can make a fix and submit a PR.
Any help is highly appreciated

I have the same problem too.
When I symbolized the AppleFormat crash log, I got the error atos cannot load symbols for the file ~/Library/Developer/Xcode/iOS DeviceSupport/14.6 (18F72) arm64e/Symbols/usr/lib/system/libsystem_c.dylib for architecture arm64.
So I changed the Binary Images architecture from arm64 to arm64e and it worked.
I debug the code to see why the architecture is wrong and found this:

I wonder if there is a way to fix this?
@happy201993 @nacho4d Have you worked it out yet? Any help is highly appreciated

@AndyXB I am still investigating this issue.
I also noted the cpusubtype is that weird number: -2147483646. KSCrash expects to be 2 so it is recognized as arm64e I wonder if we should interpret that cpusubtype in a different way (-2147483646 is Int32 min (-2147483648) plus 2 ... this is suspicious)...

In the mean time I have fixed other minor arm64e things in https://github.com/kstenerud/KSCrash/pull/415 but this main issue (the main issue) is still remaining. I am still investigating...

Update: I found the reason. KSCrash is using its own logic to calculate architecture name from cputype and cpusubtuype. It should use NXGetArchInfoFromCpuType like in this stackoverflow answer. I have tried and works great. I will update above pull request now :)

Great! LGTM! Thx.

Thanks!

Just for the record. Above pull request solves the problem but it is not merged yet. People can use my fork if needed of course.

(Unfortunately I am not supposed to use my own fork for client projects. So it would be great it @kstenerud approves it.)

@kstenerud Could you take a look at it please?

您好，我已收到您的邮件，会尽快给您回复。