EurekaLog behauptet zweifelhafte Schutzverletzung

[stahli]

Eigentlich ist das Problem nicht mehr relevant weil ich noch einiges umgestellt habe, aber mich würde interessieren, ob sich die Fehlerursache erklären lässt...


Es gibt einen Bezug auf folgenden Thread: http://www.delphipraxis.net/184063-m...interface.html

Ich habe allerdings auf Klassen umgestellt und deklariere nur noch einige Interfaces ohne Referenzzählung.
Die Interfaces sollten also keinen Einfluss auf die Lebenszeit der Objekte haben.

Ich habe eine generische Liste, in der Interfaces (vorliegend genau eines) gespeichert werden - im Sinne eines globalen Lagers.
Zum Projektende gehe ich die Liste durch und gebe die Interface-Objekte (bzw. derzeit das Eine) frei.
Wenn ich diese Funktion verlasse gibt mir EurekaLog einen Zugriffsfehler vor. Ich finde nicht heraus, wo das Problem sein soll.

Ohne EurekaLog ist kein Fehler erkennbar und auch FastMM bemeckert nichts.

Es liegt hier kein Notfall vor, aber ich kann mir einfach nicht erklären, wo hier das Problem liegt...


Anbei mal 3 Screenshots. Hat da jemand eine Idee?
Oder will mal jemand das Projekt einsehen (XE3 und EurekaLog müsste verfügbar sein)?
Ich habe das Projekt etwas entfachtet und würde das bei Interesse zumailen.

[Union]

Wo sieht man da dass es von EL verursacht bzw. gemeldet wurde? Welche EL Version? Welcher Memory Manager?

[himitsu]

Für mich sieht es nach fGuidList = nil aus. :angel:

[stahli]

@Union
... siehe Screenshot

In diesem Fall tritt der Fehler nur auf, wenn EL aktiviert ist.
Mehr Bezug habe ich nicht.

In anderen Fällen ist der Debuger in einer Unit gelandet, die darauf hinweist, dass ich keine Enterprise-Version benutze.
Das fand ich immer blöd, aber kaufen wollte ich die nicht.


@himi
Entsprechendes konnte ich nicht nachvollziehen.
Ich springe in fGuidList.FreeItems und das wird abgearbeitet.
TGuidList.Destroy wird nirgends aufgerufen.
Beim "end" der Methode ist auch noch alles i.O. (augenscheinlich).
Der Rücksprung in die aufrufende Methode klappt dann nicht mehr.

Ich habe jetzt mal try finally versucht.
Das Programm wird nach dem ersten Methodenaufruf hart beendet.
Der Schutzblock bringt dort nichts.

Delphi-Quellcode:

destructor TXXX.Destroy;
begin
  ...

  try
    fGuidList.FreeItems;
  finally // hier Programmabsturz
  end;

  try
    fGuidList.FreeItems;
  finally
  end;

  ...
  inherited;
end;

EL ist ja auch "nur Software". Vielleicht läuft dort etwas falsch?

[Union]

Das ist ja auch nicht die aktuelle Version von EL. Fehler können da natürlich sein. Schau mal unter Memory Problems ob evtl. der EL Speichermanager verwendet wird, der ist nämlich nicht der dollste.

[stahli]

Ok, ich schiebe das dann einfach mal auf ein (vielleicht veraltetes) EL-Problem.
Dann kann der Thread schlafen gehen und ich denke notfalls vielleicht mal irgendwann über ein EL-Update nach...