Problem mit FastReports und kaputt gehendem Interface

[TurboMagic]

Hallo,

gegeben Delphi 11.2 und die kostenlose FastReports Edition.
Ich habe eine Klasse zum Report erzeugen (die ein Interface umsetzt und daher immer
per Interface Referenz benutzt wird). Diese Klasse bekommt per Konstruktor mehrere
Interface Referenzen übergeben.

Das OnGetValue Event von FastReport ist in dieser Report Generator Klasse umgesetzt
um aus diesen übergebenen Interface Referenzen dynamisch auszugebende Informationen
zu beschaffen.

Das jeweils benutzte Report Objekt ist statisch auf einem Datenmodul und es wird
zur Laufzeit eine entsprechende .fr3 Datei rein geladen.

Jetzt habe ich einen reproduzierbaren Fall, wo irgendwie in dieser Report Erzeugungsklasse
die Interfacereferenz kaputt gehen muss. Ich verstehe aber noch nicht wie.

Der Fall ist vom Ablauf wie folgt:

1. Es wird im Konstruktor einer Logikklasse eine Interfacereferenz der Report
Erzeugungsklasse erzeugt "R1" und die später kaputt scheinende Interface Referenz "A",
die später Daten liefern soll übergeben.

2. Es wird in einer anderen Methode eine neue Interfacereferenz der Report
Erzeugungsklasse erzeugt "R2" und eine andere Interface Referenz "B" statt "A" übergeben,
da ggf. andere Datenwerte geliefert werden sollen. "B" ist auch in der Methode erzeugt.

3. Mittels "R2" wird erfolgreich ein Report ausgegeben. Die Aufrufende Methode mit den
lokalen Referenzen R2 und B wird verlassen.

4. Es wird versucht über "R1" einen Report auszugeben. In den Methoden vor dem
Report.PrepareReport(true); Aufruf ist der Referenzzähler von "B" auf 3.

5. In der OnGetValue Methode, die durch Report.PrepareReport(true); aufgerufen wird ist
"B" irgendwie total kaputt. Assigned ist noch true, der Versuch im Debugger RefCount
anzuzeigen (habe das im Interface rausgeführt) schlägt mit einer Zugriffsverletzung
"Unknown exception 4E3D0E80 at 0148FF84" fehl.

6. Der Versuch mal alle Debugging Optionen von FastMM4 "Vollversion" einzuschalten hat
auch nichts gebracht.

Wie kann diese Interface Referenz kaputt gehen? Das Programm macht da nix paralell...

[Uwe Raabe]

Der Fehler liegt mit ziemlich hoher Wahrscheinlichkeit in deinem Code, der vermutlich nicht vollständig dem entspricht, was du eigentlich bewirken willst. In dem Fall hilft es auch nicht, nur zu beschreiben, was der Code machen sollte. Dazu muss man schon den realen Code sehen, um zu erkennen wo Soll und Ist voneinander abweichen.

[TurboMagic]

Ja, vermutlich liegt der Fehler in meinem Code.
Nur hat der halt auch schon eine 5-stellige Zeilenanzahl und Abhändigkeiten von
verschiedenen Bibliotheken, jedoch alle kostenlos.

Nur sehe ich halt einen RefCount von 3, rufe die Report.PrepareReport(true) Methode
von FR auf und schwupps ist irgendwas an dieser Interface Referenz total kaputt.

Und nein, hier werden zumindest in meinem Code nicht Interface Referenzen und
Objektreferenzen gemischt...

[dummzeuch]

Ein solches Problem hatte ich mal, weil ein Interface Parameter als const deklariert war. const weg -> Fehler weg. Deshalb habe ich es mir abgewöhnt, sie so zu deklarieren.

Ist vielleicht einen Versuch wert, denn schaden sollte es kaum.

[TurboMagic]

Hallo,

danke für die Antworten.
Ich hab's jetzt anders gelöst und es scheint zu funktionieren.
Ich hab der Reportgenerator Klasse jetzt noch eine neue Methode spendiert,
mit der man die beiden Interface Referenzen neu zuweisen kann, die im betreffenden
Fall die Daten ausgetauscht haben müssen. Nach erfolgreicher report Generierung
wird das dann einfach nochmal mit den normalerweise benutzten Interface Referenzen
aufgerufen, also zurück getauscht.

Dadurch muss man von dem Report Generator nicht noch eine zweite Instanz erzeugen.
Erste Tests waren jedenfalls positiv.

Zu Interfaces also Const Parameter: vermutlich wird da der Referenzzähler dann nicht
hochgesetzt...

Grüße
TurboMagic

[mjustin]

Zitat von TurboMagic:

Zu Interfaces also Const Parameter: vermutlich wird da der Referenzzähler dann nicht
hochgesetzt...

Ja, sobald const verwendet wird kommt es nicht zur Erhöhung des Referenzzählers (und das ist gut so). Ausserdem wird kein try..finally generiert.
Es ist aber nicht notwendig, nun jedes const vor einem Interface-Parameter zu entfernen. Es gibt nur eine Konstellation, bei der das const zu einem Fehler führt:

Angenommen diese Methode soll verwendet werden:

procedure Frob(const Grob: IGrobber); Dann kommt es zu einem Fehler bei der Referenzzählung wenn sie so aufgerufen wird:

Frob(TGrobberImplementer.Create); Dies dagegen funktioniert:

Delphi-Quellcode:

grob := TGrobberImplementer.Create;
Frob(grob);

(Beispiele aus: "Should I not pass an interface as const?" - https://stackoverflow.com/a/31028671/80901)

Ich verwende generell const für Interface-Parameter, und achte einfach nur darauf, immer erst eine Instanz zu erstellen und diese dann zu übergeben.

Da sich fehlerhafte Referenzzählung unter anderem zu nicht freigegebenen Objekten führen kann, verwende ich ausserdem das gute alte ReportMemoryLeaksOnShutdown := True.