BPL Zugriffsverletzung

[jaenicke]

Zitat von haentschman:

Delphi-Quellcode:

IDVAParser = interface(IInterface)
    ['{7082CCBB-2680-4BC4-8B17-7FFE1D602A0A}']

    procedure ParseDevice(const aText: PChar; DeviceList: TDeviceList);
...
  end;

So ähnlich sieht das bei uns auch aus, allerdings sind das dann nicht Parameter vom Typ TDeviceParameterList sondern vom Typ IInterfacedList<IDeviceParameter>...

Deine Funktionen sehen ja so aus als ob die Objekte nur übergeben und innerhalb der Funktion verwendet werden. Insofern hast du mit dem Lebenszyklus auch keine Probleme (da du Interfaces und Objekte mischst). Allerdings heißt die BPL-Hölle nicht umsonst so. Ganz sorglos mit Objekten werfen kann man da auch nicht.
Allerdings weiß ich das nicht genauer, da ich immer sauber komplett mit Interfaces gearbeitet habe und das Problem daher nie hatte.

Hast du vielleicht einmal einen Stacktrace von einem solchen Fehler und den Quelltext an der Stelle und kannst das zeigen?
Generell:
Wenn irgendwo nil drin steht, wo es nicht drin stehen sollte, würde ich das ganze in Getter und Setter auftrennen und einen Haltepunkt auf den Setter setzen mit "wenn nil übergeben wird" als Bedingung. Alternativ könntest du auch einen Datenhaltepunkt nutzen.

Zitat von haentschman:

Zitat:

Erstens dürfen in dem Interface selbst keinerlei Objektreferenzen vorkommen.

Wo steht das? Bei DLL kann ich das nachvollziehen. Bei BPL nicht.

Das habe ich ja auch geschrieben, bei BPL geht es. Allerdings macht dann das Interface wenig Sinn, dann kannst du auch gleich konsistent bleiben und ein Objekt zurückgeben. Mischen von Objektreferenzen und Interfaces ist immer schlecht.

[haentschman]

Zitat:

dann kannst du auch gleich konsistent bleiben und ein Objekt zurückgeben

...sind viele verschiedene Objekte da der Parser sich in der Funktion unterscheiden kann (Text unterschiedlich) Deshalb das Interface. Der Thread arbeitet mit dem Interface. Da ist es wurscht ob Tbla oder TBlubb hinten dran hängt.

Meinst du wenn ich statt der Objektliste eine Interface Liste übergebe und die (zu ergänzenden) Interfaces der im Parser erzeugten Objekte hineinlege habe ich weniger Probleme?

Zitat:

Hast du vielleicht einmal einen Stacktrace von einem solchen Fehler

...nicht als Bild. Die letzte Zeile vor einer der Zugriffsverletzungen war:

Delphi-Quellcode:

procedure TXWebBaseParser.ParseAlarm(const aText: PChar; AlarmList: TAlarmList);
var
  aAlarm: TAlarm;
  I, PositionFirst, PositionCount, TempPosition: Integer;
  sl: TStringList;
begin
  AlarmList.Clear; //<- hier. Klingt als wäre die Objektliste nicht existent. Diese wird aber beim Erzeugen des Threads erzeugt und im Destroy freigegeben.
  sl := TStringList.Create;
.
.

...deshalb vermute ich die Fehler in der Speicherverwaltung weil ich mit den Objekten nicht richtig umgehe. Mich interessiert halt wie es richtig geht. Deine Variante, grundsätzlich alles mit Interfaces, werde ich mal ausprobieren. Leider erst nächstes Wochenende.

Danke...

[jaenicke]

Zitat von haentschman:

Klingt als wäre die Objektliste nicht existent. Diese wird aber beim Erzeugen des Threads erzeugt und im Destroy freigegeben.

FreeOnTerminate nutzt du aber hoffentlich nicht, oder? Denn dann dürftest du auf das Threadobjekt nicht von außen zugreifen.

Das würde das aber direkt erklären.

[haentschman]

Der Thread hält die Instanzen der Objektlisten und übergibt sie dem Parser ParseAlarm(const aText: PChar; AlarmList: TAlarmList) Die kann nicht nil sein.
Wenn ich die Klasse direkt instanziere ist ja Alles in Ordnung. Deswegen tippe ich auf ein falsches Abbiegen im Speicher.

Nachtrag: FreeOnTerminate benutze ich nicht.

[jaenicke]

Dann bleibt noch FastMM versuchen und eben Haltepunkte mit der Bedingung, dass die Variable nil ist.