Kscrash: AppleFormatReportのバイナリイメージアーチが間違っていますか？

私も同じ問題を抱えていると思います。 これを修正する方法があるのだろうか？

@kstenerudこんにちは、これを修正する方法を知っているかしら？ あなたが私にいくつかの指針または見始める場所を与えてくれれば、私は修正をしてPRを提出することができます。
どんな助けでも大歓迎です

私も同じ問題を抱えています。
AppleFormatクラッシュログをシンボル化すると、エラー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.が発生しました
そこで、バイナリイメージアーキテクチャをarm64からarm64eに変更すると、機能しました。
コードをデバッグして、アーキテクチャが間違っている理由を確認し、次のことを見つけました。

これを修正する方法があるのだろうか？
@ happy201993 @ nacho4dもう解決しましたか？ どんな助けでも大歓迎です

@AndyXB私はまだこの問題を調査しています。
また、cpusubtypeがその奇妙な数であることに気づきました： -2147483646 。 KSCrashは2であると想定しているため、arm64eとして認識されます。そのcpusubtypeを別の方法で解釈する必要があるのではないかと思います（-2147483646はInt32分（-2147483648）プラス2 ...これは疑わしいです）...

その間に、 https： //github.com/kstenerud/KSCrash/pull/415で他のマイナーなarm64eの問題を修正しましたが、この主要な問題（主要な問題）はまだ残っています。 私はまだ調査中です...

更新：理由を見つけました。 KSCrashは、独自のロジックを使用して、cputypeおよびcpusubtuypeからアーキテクチャ名を計算しています。 このstackoverflowの回答のようにNXGetArchInfoFromCpuTypeを使用する必要があります。 私は試してみて、うまくいきました。 上記のプルリクエストを今すぐ更新します:)

すごい！ LGTM！ どうも。

ありがとう！

記録のためだけに。 上記のプルリクエストは問題を解決しますが、まだマージされていません。 もちろん、必要に応じて人々は私のフォークを使うことができます。

（残念ながら、私はクライアントプロジェクトに自分のフォークを使用することは想定されていません。したがって、 @kstenerudがそれを承認するのは素晴らしいことです。）

@kstenerud見ていただけませんか？

こんにちは、私はあなたの電子メールを受け取りました、そしてできるだけ早く返事をします。