System Library.
I got arch arm64,but acturally is arm64e
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?
您好,我已收到您的邮件,会尽快给您回复。
Most helpful comment
Great! LGTM! Thx.