sporadische Exception beim Freigeben von TLabels

[Gausi]

Danke schonmal für die Antworten.

Nein, Threads habe ich an der Stelle nicht. Ich klicke auf ein Element in einer VirtualTreeView, und zeige im "onClick" die Elementeigenschaften an. Ein Teil davon ist das Erzeugen dieser Labels. Ich nutze zwar durchaus mehrere Threads für einige Hintergrundarbeiten, aber die Labels sind rein VCL-Thread. das würde auch öfter knallen, denke ich.

FastMM habe ich mal probiert (du meinst doch das hier, oder? https://github.com/pleriche/FastMM4). Tatsächlich zeigt der mir am Ende an, dass etwas doppelt freigegeben wird, aber das hat hiermit nichts zu tun - da gibt es noch ein Problemchen im Finalize einer Unit. Wenn ich das (erstmal Quick&Dirty, so ganz gefällt mir die Lösung noch nicht) ins OnDestroy der MainForm verschiebe, gibt es keine solche Meldung mehr.

Die Label liegen auf einem Panel (bzw. auf einer eigenen Ableitung davon). Dieses Panel bleibt aber zur Laufzeit erhalten. Die Objekte in der Liste sollten also nicht "von außen" gelöscht werden können. Die TComponentList schaue ich mir aber auch nochmal an. Ob dadurch der Fehler behoben wird, kann ich aber ohne Reproduktionsweg nicht so richtig testen ...

Zitat von himitsu:

TComponents haben aber ein intenes Notifications-Systen, womit man sich informieren lassen kann, wenn es freigegeben wird. (das nutzt der Owner, Parent und z.B. eine ComponentList)

Jep, das wird hier ja auch getriggert. Durch das Clear der ObjectList wird für jedes Objekt (=TLabel), das jetzt zerstört werden soll, das Parent informiert. Das Parent löscht die Referenz darauf, und ruft dann noch AlignControls auf (auch wenn das hier nicht nötig wäre, da die Labels alle alNone sind). Und dabei kommt die Exception. Meine Vermutung war also, dass das Parent doch noch Referenzen auf Objekte hat, die die Liste schon fertig zerstört hat. Aber das sollte nicht passieren, wenn ich mir den Code von TObjectList.Clear so anschaue und von all dem Gedöns, was da dranhängt ...

[Uwe Raabe]

Du könntest das Clear in ein DisableAlign/EnableAlign des Panels kapseln.

[himitsu]

Ansonsten bliebe noch dieses grauenhafte DebugDCUs wieder zu aktivieren und zu hoffen dann mehr sehen zu können.

Das Einzige, was wie ein "Offset" von 8 ausssieht, welches ich auf die Schnelle sah, wäre ResizeList.Capacity, bzw. das FCapacity.

[Gausi]

Zitat von Uwe Raabe:

Du könntest das Clear in ein DisableAlign/EnableAlign des Panels kapseln.

Ah, so heißt das. Ich hatte BeginUpdate/EndUpdate probiert, aber das gibt es bei Panels ja nicht.

Ich habe jetzt die Liste zu einer TComponentList gemacht (weitere Änderungen neben der Deklaration und dem Create scheinen nicht nötig zu sein), und das Clear gekapselt wie Uwe es vorgeschlagen hat. Das sollte reichen. Falls nicht, muss ich später nochmal genauer schauen ...

[TigerLilly]

Möglicherweise führt das Freigeben des Labels zu einer Aktualisierung des Parents der noch nicht weiß, dass der Label freigegeben ist? Siehe auch Post von Uwe Raabe.

[ConnorMcLeod]

Mglw ist FreeNotification Dein Freund.

[DenkDirNix]

Vielleicht ein WorkAround:
Vor dem Löschen eines Labels den Parent auf nil setzen.

[Gausi]

Wie gesagt, ich habe jetzt zwei Vorschläge von hier in den Code übernommen und hoffe, dass das Problem damit behoben ist.

Beim Clear der Objectlist werden die einzelnen Controls freigegeben. Dabei wird (unter anderem) der Parent auf Nil gesetzt, wodurch das Parent benachrichtigt wird, dort wird es aus den Child-Controls ausgetragen etc. pp. Beim Realign des Parents kommt es dann aus unbekannter Ursache selten (sehr selten) zu einem Problem. Wenn man das unterbindet, sollte das erledigt sein.

Die Funktion wird sehr oft aufgerufen (praktisch immer, wenn man ein Item auswählt), und ich habe nie Probleme damit beobachten können. Threads spielen an der Stelle keine Rolle - oder allenfalls indirekt, falls freigegebener Speicher "zu schnell" wieder von einem anderen Thread beansprucht wird. Dann aber sollte die Zugriffsverletzung eher an einer zufälligen Adresse passieren, und nicht an $08.
Diese Labels werden auch nicht an vielen Stellen im Code benutzt. Sie werden zur Anzeige erstellt, dargestellt, und jedes Label bekommt ein paar EventHandler (MouseEnter/Leave für Underline-Effekt, OnDoubleClick). Das wars auch schon, kein wilder Spaghetti-Code dabei.

Ein offensichtlicher Konzeptfehler liegt wohl nicht vor (sonst gäbe es andere Antworten, schätze ich ). Von daher habe ich das jetzt (erstmal) abgehakt. Nach dem nächsten Release schau ich dann mal weiter.

[TigerLilly]

Zitat von DenkDirNix:

Vielleicht ein WorkAround:

Ein Workaround ohne die Ursache zu kennen ist böse.