Hallo,

in einer Android App habe ich seit Umstellung auf 10.4.x ein Problem mit einem Crash.
Dank Debugger bin ich ein wenig weiter.

Es gibt in der App ein selber geschriebenes Interface und dessen Referenz soll
an einen Konstruktor einer Klasse übergeben werden die von TThread abstammt.

Kommt man das erste Mal da vorbei ist noch alles gut und die App tut was sie soll.
Kommt man später wieder dran vorbei und der RefCount im Interface scheint 0.

Kommt man später wieder an die Stelle knallt es bei der Übergabe des Interfaces
und wenn man sich direkt davor den RefCount anschaut, ist der total verbogen.
Astronomisch hoch oder auch negativ.

Die einzige Stelle, an der ein Free auf das Feld, welches dieses Interface
bereit stellt gemacht wird (ja, soll man nicht), wird lt. Debugger nicht
angesprungen.

Woran kann es noch liegen?

Grüße
TurboMagic

Bei einer eigenen Klasse, die das Interface implementiert, ist das sehr einfach:
Überschreibe einfach _Release und setze dort einen Haltepunkt.

Eine mögliche Ursache:
Du übergibst ein Objekt direkt über den Aufruf des Konstruktors als konstanten Parameter.

markieren

Delphi-Quellcode:

procedure Blub(const AData: IInterface);
...
Blub(TMyClass.Create);

An der Stelle funktioniert die Referenzzählung nicht korrekt, weshalb man die Instanz immer zuerst in eine Interfacevariable speichern muss. Diese Variable kann man dann an die Methode übergeben:

markieren

Delphi-Quellcode:

Test := TMyClass.Create;
Blub(Test);

Danke, das sind schon mal 2 verfolgenswerte Ansätze.
Was mich etwas wundert ist halt, dass es unter 10.3.3 noch funktionierte.
Aber da ich nicht genau weiß, wass seit dem alles wegen ARC Ablösung
geändert wurde versuche ich es erstmal mit den Ansätzen.

ARC wurde doch in den letzten Delphis nochmal umgebaut?

Aber egal, hier geht es eh nicht um ARC, da die Referenzzählung bei den Interfaces überall gleich ist.


Willst du das dennoch als Einzeiler haben, dann bau dir ein eigenes "Create", welches als "class function" direkt das IInterface bzw. IMyClass zurück gibt.

Zitat von jaenicke:

Bei einer eigenen Klasse, die das Interface implementiert, ist das sehr einfach:
Überschreibe einfach _Release und setze dort einen Haltepunkt.

Eine mögliche Ursache:
Du übergibst ein Objekt direkt über den Aufruf des Konstruktors als konstanten Parameter.

markieren

Delphi-Quellcode:

procedure Blub(const AData: IInterface);
...
Blub(TMyClass.Create);

An der Stelle funktioniert die Referenzzählung nicht korrekt, weshalb man die Instanz immer zuerst in eine Interfacevariable speichern muss. Diese Variable kann man dann an die Methode übergeben:

markieren

Delphi-Quellcode:

Test := TMyClass.Create;
Blub(Test);

Habe ein wenig damit rumgespielt und folgendes ermittelt:

1. Habe _AddRef und _Release beide überschrieben und darin sowohl einen Breakpoint gesetzt als auch
eine LogCat Logmeldung ausgegeben
2. Beide werden nie aufgerufen
3. Es gibt eine Klasse, die hat ein Feld von der Klasse die das Interface implementiert.
Dem Feld wird mittels <Klassenname>.Create(...); die Objektreferenz zugewiesen und dieses Feld
wird später an den Constructor des Threads übergeben (genauer: das Property davon, welches direkt
auf das Feld durchgreift).

Was nun? Das Interface deckt bisher leider nicht die komplette Funktionalität der Klasse ab.
Man könnte es ggf. erweitern und dann statt einer normalen Objektreferenz für das Feld gleich das
Interface benutzen. Würde das die Sache besser machen?

Zitat von TurboMagic:

3. Es gibt eine Klasse, die hat ein Feld von der Klasse die das Interface implementiert.
Dem Feld wird mittels <Klassenname>.Create(...); die Objektreferenz zugewiesen und dieses Feld
wird später an den Constructor des Threads übergeben (genauer: das Property davon, welches direkt
auf das Feld durchgreift).

Wenn du die Instanz in einer Objektreferenz speicherst, darfst du entweder nie (!) das Interface verwenden oder du musst die Referenzzählung in der Klasse deaktivieren (sprich statt TInterfaceObject als Basisklasse einfach TSingletonImplementation aus System.Generics.Defaults verwenden).

Zitat von TurboMagic:

Was nun? Das Interface deckt bisher leider nicht die komplette Funktionalität der Klasse ab.
Man könnte es ggf. erweitern und dann statt einer normalen Objektreferenz für das Feld gleich das
Interface benutzen. Würde das die Sache besser machen?

Ja, eindeutig. Du kannst auch ein zweites Interface dafür verwenden und mit as / Supports casten, wenn diese Funktionalität nicht offen verfügbar sein soll.

Man kann eine Instanz einer Klasse nach der Erstellung auch durchaus in eine Objektreferenz packen und z.B. mit Daten füttern und erst danach in eine Interfacereferenz packen, die diese Möglichkeiten nicht bietet. Aber danach darf man die Objektreferenz nie wieder verwenden (am besten direkt auf nil setzen), da man ja nie weiß wann das Objekt über das Interface freigegeben wird (wodurch das Objekt aus der Objektreferenz ungültig ist). Außerdem wird das Objekt freigegeben, sobald das Objekt als Interface weitergegeben wurde und die Interfacereferenzen aus dem Scope laufen oder nil werden. Denn es gibt ja keine dauerhaft aktive Interfacereferenz, wenn es als Objektreferenz gespeichert wird...

Zitat von TurboMagic:

1. Habe _AddRef und _Release beide überschrieben und darin sowohl einen Breakpoint gesetzt als auch
eine LogCat Logmeldung ausgegeben

Das verstehe ich bei Verwendung des Interfaces nicht. Aber ohne Quelltext kann ich dazu auch nicht viel mehr sagen.

Nach Umstellung der implementierenden Klasse auf TSingletonImplementation sehen die ersten Tests gut aus.

Du solltest dann nur nicht die von dir erwähnte Freigabe mit Free am Ende (im Destruktor der Klasse, in der sich das Feld befindet) vergessen. Ohne Referenzzählung funktionieren die Instanzen ja wie einfache Objekte und müssen entsprechend auch normal freigegeben werden.

Zitat von jaenicke:

Du solltest dann nur nicht die von dir erwähnte Freigabe mit Free am Ende (im Destruktor der Klasse, in der sich das Feld befindet) vergessen. Ohne Referenzzählung funktionieren die Instanzen ja wie einfache Objekte und müssen entsprechend auch normal freigegeben werden.

Recht hast du, da hab' ich aber selber schon dran gedackt. Danke!