EOutOfResources erzeugt Speicherleck

[Schorschi5566]

Hallo zusammen,

nochmals vielen Dank für die rege Beteiligung.

@littleDave: Klingt plausibel, funktioniert aber irgendwie nicht. Der Inhalt von PBoolean(cardinal(e) + delta)^ ist zwar False und wird dementsprechend auf True gesetzt, aber die Meldung vom Speichermanager (der bei Delphi2010 ja wohl FastMem ist) bleibt die gleiche.

@himitsu: Es geht ja nicht darum, dass ich die Exception auslösen, sondern dass ich darauf reagieren will. Mache ich ja auch, nur bleibt dabei eben die Exception übrig.

[littleDave]

Ah, du hast Delphi 2010, da musst du es so machen:

Delphi-Quellcode:

    on e: EOutOfResources do
    begin
      delta := cardinal(EHeapException.ClassParent.InstanceSize) - SizeOf(Pointer); // den Offset zur Boolean-Variable auslesen
      PBoolean(cardinal(e) + delta)^ := True; // "AllowFree" auf "True" setzen (Offset + Instance-Pointer = Heap Pointer)

    end; // <-- hier wird die Exception dann automatisch freigegeben (siehe auch: AcquireExceptionObject, etc.)

In Delphi 2010 wird an das Ende der Klasseninstanz noch eine TMonitor-Referenz gespeichert. Daher muss der Pointer auf diese Referenz vom Offset noch abgezogen werden.

[himitsu]

Ich sag ja, ist ein Fehler in Delphi.
Diese Exception dürfte erst garnicht ständig neu erzeugt werden ... wie es richtig geht, sieht man an EOutOfMemory.
Aber man kann es eh nicht ordentlich implementieren, da AllowFree privat ist und somit in anderen Units nicht nutzbar ist.
(sowas gehört in protected)

Fazit: Dieses Singleton ist fehlerhaft implementiert und falsch verwendet.

[littleDave]

Die EOutOfResources-Exception müsste im Constructor automatisch die "AllowFree"-Variable auf True setzen oder nicht von EHeapException abgeleitet sein. Diese Exception soll ja darauf hinweisen, dass keine Handles mehr zur Verfügung stehen - jedoch braucht eine Exception an sich kein Handle und sollte somit eigentlich ohne Probleme erstellt werden können (im Gegensatz zur EOutOfMemory-Exception) - auch wenn das System keine Handles mehr hat.

[himitsu]

Auch EOutOfMemory ist schon fehlerhaft implementiert.

Bei diesen Exceptions müßten nicht nur die globalen Exceptionobjekte schon erstellt worden sein, sondern auch schon das ganze Meldungsfenster.

Bei EOutOfResources braucht man zwar für das Exceptionobjekt kein Handle, aber für das Fehlerfenster schon.

[littleDave]

Als fehlerhaft würde ich das nicht bezeichnen, denn es muss ja nicht unbedingt ein Fester geben (Console-Anwending, Service, etc.). Daher finde ich diese pauschale Bezeichnung falsch. Zudem ist bei diesen Fehlern wichtig, dass man vorher nicht mehr benötigte Resourcen freigibt, bevor eine Meldung angezeigt wird.

[himitsu]

EOutOfResources ist in Classes deklariert, wärend EHeapException in SysUtils deklariert ist.
Da AllowFree aber als Privat deklariert ist, kann man externe Nachkommen von EHeapException überhaupt nicht ordnungsgemäß verwenden.

[littleDave]

Klar, die Variable gehört in protected - ich meinte eher, dass es falsch wäre, das Meldungsfenster gleich mit zu initialisieren.

[Schorschi5566]

So, jetzt ist die Meldung weg. Super und nochmals danke.

Warum überhaupt eine EOutOfResources kommt, ist mir zwar immer noch nicht wirklich klar aber zumindest bleiben die Exceptions jetzt nicht mehr im Speicher hängen.

In meinem Fall werden doch nur einige GDI-Handles angefordert. Wird der dafür nötige Speicher ebenfalls gleich mitbestellt (dann wäre es logisch) oder wie muss man sich das vorstellen?

Das Programm hat zur Laufzeit zwischen 100-120 der GDI-Handles, Tendenz gleichbleibend.

[Luckie]

Also ich halte es immer noch für falsch bewusst in eine Exception reinzulaufen. Ich meine, ich lasse Autos ja auch nicht bewusst an einer Ampel Unfälle bauen und stelle einen Abschleppwagen da neben, um die Wracks weg zu räumen.