Ios9

[cipher]

Zitat von Rollo62:

Jetzt denke ich doch das es eher von der ImageList kommt, die PNG-Dateien habe ich schon mit IrFanView
upgedated, damit war es jedenfalls imer in Ordnung.

Wenn vielleicht jemand etwas dieser Richtung gefunden hat wäre ich für einen Tipp sehr dankbar.
Im Moment weiss ich nicht was von 32 zu 64-Bit schiefläuft.

Probleme mit der ImageList kann ich definitiv bestätigen. Habe sie in meinem Projekt daher komplett entfernt.
Jetzt läuft die App unter iOS 64bit.
Aber es scheint noch eine Komponente zu geben, die bei mir unter 32bit Probleme macht. Das ist echt ätzend. Vor allem läuft die App auch unter Android bei mir nur noch im Debug Mode aber nicht als Release.
Ich habe irgendwo gelesen, dass es auch ein Problem mit der Push-Komponente im Zusammenhang mit Parse geben könnte.

[Rollo62]

Hallo cipher,

also ich geb dem Ding noch eine Chance.
Ich habe jetzt alle Images aus der TImageList entfernt, und nochmal neu angelegt.
Es könnte sein das ein Bild verschoben/umbenannt worden ist.

Das sollte eigentlich kein Problem sein, weil in TImageList *.fmx Datei die Bilder als Binary gespeichert sind,
nur ist auch noch zusätzliche ein Link zum Orginalbild vorhanden.
Dummerweise mit absoluten Pfaden, so dass ein Verschieben ins Nirwana führt.

Trotzdem bin ich nicht sicher ob es daran gelegen hat, weil ja die App auf ALLEN Plattformen korrekt
lief, von Win32/64, über Mac, iOS32/Simulator, Android.
Nur eben der iOS64 ist gecrasht, das ist schon seltsam.

Nach dem kompletten Löschen, Neuanlegen der Bilder hat es dann auch bei IOS64 funktioniert,
also definitiv ein TImageList Problem.
Aber das möchte ich nicht nochmal bei einem größeren Projekt machen, mit zig Icons ...

Was lerne ich daraus: Ich werde in Zukunft direkt auf iOS64 debuggen, statt wie bisher auf iOS32,
um vielleicht solche Probleme ehere zu erkennen.

Im übrigen hatte ich ähnliche Probleme mit Styles, auch da denke ich das es verwaiste Bilder/Stile sind
die das Ganze zum crashen bringen können.


Rollo

[cipher]

Nach kleiner Pause habe ich mich jetzt wieder an mein kleines Projekt gesetzt um endlich einmal den Fehler etwas einzugrenzen.

Phänomen bei mir: meine App läuft auf 32-Bit-Geräten nur wenn als "Debug" kompiliert. Auf 64-Bit-Geräten dagegen sowohl als "Release" als auch "Debug".

Ich habe mich bei den Compiler-Einstellungen durch die Unterschiede zwischen Release und Debug geklickt und bin schlussendlich zu folgender Einstellung gekommen:

Wenn ich für die iOS32-Bit-Debug Version "Mit Debug-DCUs" auf "True" setze (siehe Bild), dann läuft die App auch als "Release" kompiliert.

http://enlightme.info/ios.png

Hat hier jemand evtl. einen Tipp, warum das so ist oder wie man das noch weiter eingrenzen könnte?

[Sir Rufo]

Einen Fehler bzgl. iOSDevice32/Release habe ich schon gemeldet
https://quality.embarcadero.com/browse/RSP-12408

Du solltest aber irgendeine Fehlermeldung bekommen, bzw. deine App mit ein wenig Logging bestücken damit du sehen kannst wo der Fehler herkommt.

[cipher]

Das Problem ist, dass die App schon abstürzt bevor sie dazu kommt meinen Code auszuführen (also noch beim "booten"):

http://enlightme.info/crash.png

Ich habe den Fehler jetzt eingrenzen können:

Es handelt sich um einen Bug im Zusammenhang mit TPushEvents. Dieses Feature scheint unter Android & iOS32-Bit im Release Mode zum Crash zu führen.

https://quality.embarcadero.com/browse/RSP-12658

Tolle Wurst, da bleibt mir wohl nichts anderes, als abzuwarten bis Embarcadero einen Fix dafür erstellt.

[cipher]

Zitat von Sir Rufo:

Einen Fehler bzgl. iOSDevice32/Release habe ich schon gemeldet
https://quality.embarcadero.com/browse/RSP-12408

Du solltest aber irgendeine Fehlermeldung bekommen, bzw. deine App mit ein wenig Logging bestücken damit du sehen kannst wo der Fehler herkommt.

Das war ein guter Tipp von dir! TPushEvents scheint auch die Supports-Methode aus System.SysUtils zu nutzen, die bei Android/Release und iOS32/Release zum Absturz führt.

Als Workaround habe ich die System.SysUtils.pas in meinen Projektpfad aufgenommen und folgende Methode:

Code:

function Supports(const Instance: IInterface; const IID: TGUID; out Intf): Boolean; overload;

so verändert:

Code:

function Supports(const Instance: IInterface; IID: TGUID; out Intf): Boolean; overload;

Warum das dann funktioniert, weiß ich aber nicht.

[Memnarch]

Ich vermute es liegt dann an dem const der TGUID. IIRC wird ohne const der record zuerst kopiert und dann an die Funktion übergeben. Mit const wird nur eine reference zu dem record auf den stack gepushed. Das heißt du pushed eine reference auf den stack, während dort eigentlich der record direkt erwartet wird. Innerhalb der Funktion wird dann wohl auf invaliden Speicher zugegriffen.

[cipher]

Zitat von Memnarch:

Ich vermute es liegt dann an dem const der TGUID. IIRC wird ohne const der record zuerst kopiert und dann an die Funktion übergeben. Mit const wird nur eine reference zu dem record auf den stack gepushed. Das heißt du pushed eine reference auf den stack, während dort eigentlich der record direkt erwartet wird. Innerhalb der Funktion wird dann wohl auf invaliden Speicher zugegriffen.

Ja, das könnte sein, aber die IID wird in dieser Methode auch nur als const weitergegeben:

Code:

function Supports(const Instance: IInterface; IID: TGUID; out Intf): Boolean;
begin
  Result := (Instance <> nil) and (Instance.QueryInterface(IID, Intf) = 0);
end;

Definition der QueryInterface:

Code:

function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;