Kscrash: AppleFormatReport binärer Bilderbogen ist falsch?

Erstellt am 7. Apr. 2021  ·  10Kommentare  ·  Quelle: kstenerud/KSCrash

Systembibliothek.
Ich habe Arch Arm64, aber eigentlich ist Arm64e

Hilfreichster Kommentar

Toll! LGTM! Vielen Dank.

Alle 10 Kommentare

image

Ich glaube, ich habe das gleiche Problem. Ich frage mich, ob es eine Möglichkeit gibt, dies zu beheben?

@kstenerud Hallo, ich frage mich, ob Sie eine Möglichkeit kennen, dies zu beheben? Wenn Sie mir einige Hinweise oder einen Ort geben, an dem ich anfangen kann, nachzusehen, kann ich eine Lösung finden und eine PR einreichen.
Jede Hilfe wird sehr geschätzt

Ich habe auch das gleiche Problem.
Als ich das Absturzprotokoll von AppleFormat symbolisierte, bekam ich den Fehler 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.
Also habe ich die Binary Images-Architektur von arm64 auf arm64e geändert und es hat funktioniert.
Ich debugge den Code, um zu sehen, warum die Architektur falsch ist, und habe Folgendes gefunden:
image
Ich frage mich, ob es eine Möglichkeit gibt, dies zu beheben?
@ happy201993 @nacho4d Hast du es schon ausgearbeitet? Jede Hilfe wird sehr geschätzt

@AndyXB Ich untersuche dieses Problem noch.
Ich habe auch bemerkt, dass der cpusubtype diese seltsame Zahl ist: -2147483646 . KSCrash erwartet 2, also wird es als arm64e erkannt. Ich frage mich, ob wir diesen cpusubtype anders interpretieren sollten (-2147483646 ist Int32 min (-2147483648) plus 2 ... das ist verdächtig) ...

In der Zwischenzeit habe ich andere kleinere arm64e-Probleme in https://github.com/kstenerud/KSCrash/pull/415 behoben, aber dieses Hauptproblem (das Hauptproblem) bleibt bestehen. Ich recherchiere noch...

Update: Ich habe den Grund gefunden. KSCrash verwendet seine eigene Logik, um den Architekturnamen aus cputype und cpusubtuype zu berechnen. Es sollte NXGetArchInfoFromCpuType wie in dieser Stackoverflow-Antwort verwenden . Habe ich ausprobiert und funktioniert super. Ich werde die obige Pull-Anforderung jetzt aktualisieren :)

Toll! LGTM! Vielen Dank.

Danke!

Nur für das Protokoll. Die obige Pull-Anfrage löst das Problem, ist aber noch nicht zusammengeführt. Die Leute können natürlich meine Gabel benutzen, wenn sie gebraucht werden.

(Leider soll ich meinen eigenen Fork nicht für Kundenprojekte verwenden. Es wäre also großartig, wenn @kstenerud ihn genehmigt.)

@kstenerud Könntest du es dir bitte ansehen?

Hallo, ich habe Ihre E-Mail erhalten und werde so schnell wie möglich antworten.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen