Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AppleFormatReport binary Images arch is wrong? #403

Closed
happy201993 opened this issue Apr 7, 2021 · 10 comments · Fixed by #415
Closed

AppleFormatReport binary Images arch is wrong? #403

happy201993 opened this issue Apr 7, 2021 · 10 comments · Fixed by #415

Comments

@happy201993
Copy link

System Library.
I got arch arm64,but acturally is arm64e

@happy201993
Copy link
Author

image

@nacho4d
Copy link
Contributor

nacho4d commented Aug 17, 2021

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

@nacho4d
Copy link
Contributor

nacho4d commented Aug 17, 2021

@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

@AndyXB
Copy link

AndyXB commented Sep 2, 2021

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:
image
I wonder if there is a way to fix this?
@happy201993 @nacho4d Have you worked it out yet? Any help is highly appreciated

@nacho4d
Copy link
Contributor

nacho4d commented Sep 4, 2021

@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 #415 but this main issue (the main issue) is still remaining. I am still investigating...

@nacho4d
Copy link
Contributor

nacho4d commented Sep 4, 2021

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 :)

@AndyXB
Copy link

AndyXB commented Sep 5, 2021

Great! LGTM! Thx.

@happy201993
Copy link
Author

Thanks!

@nacho4d
Copy link
Contributor

nacho4d commented Dec 16, 2021

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?

@happy201993
Copy link
Author

happy201993 commented Dec 16, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants