Schutzverletzung bei Programmende

[freimatz]

Hallo,
ich bekommen manchmal Schutzverletzung beim Programmende. Programmausführung aus Delphi XE2. Der Debugger hängt in unit FastMM4, Methode "RemoveMediumFreeBlock" bei Zeile "mov TMediumFreeBlock[edx].NextFreeBlock, ecx". CallStack:

Code:

FastMM4.RemoveMediumFreeBlock(???)
FastMM4.FastFreeMem(???)
:00414f89 RemoveMediumFreeBlock + $9
System.FinalizeUnits
:004d4bc2 InterceptFinalizeUnits + $5A
:766e8654 KERNEL32.BaseThreadInitThunk + 0x24
:77394a47 ; 
:77394a17 ;

Danach kann ich in der Methode procedure FinalizeUnits auf die Zeile nach except einen breakpoint setzen.
Wenn ich weiterlaufen lasse, dann steht der Debugger dort. Dort gibt es ein "InitContext". Die Daten darin sagen mir nicht saußer InitContext.Module.TypeInfo.Unitnames welches ein unitname enthält. An der unit habe ich auch gearbeitet. Die unit enthält kein finalization Abschnitt.

Ein finalization habe ich nun hinzugefügt und ein Aufruf einer leeren Methode. Nun tritt der Fehler nicht mehr auf.
Trotzdem würde ich gerne wissen was da schief lief.

[himitsu]

Zitat von freimatz:

Die unit enthält kein finalization Abschnitt.

Und globale Variablen oder Klassenvariablen (class var)?
Die werden ebenfall in der Unit-Finalization freigegeben.

[hoika]

Hallo,

Benutzt du Generics?

Diese leere Methode verschiebt Dein Problem jetzt nur ein bisschen.
Es kann auch wieder auftauschen, wenn z.B. die Unit-Reihenfolge geändert wird.

[freimatz]

Hallo,
Danke für die Antworten. Ja ich fürchte auch, dass das Problem nur verschoben ist.
Globale Variablen oder Klassenvariablen verwende ich nicht. Derzeit sind nur drei Methoden drin.
Generics dagegen verwende ich und zwar ein Typ der abstammt von IList<> aus Spring.Collections.

[hoika]

Hallo,


1. nimm mal FastMM4, vielleicht wird irgendwo Speicher überschrieben
2. klammer den ganzen Code aus und nimm ihn dann schrittweise wieder rein, bis der Fehler auftritt.


Der 2. Punkt heißt, dass du die leere Methode wieder deaktivierst, um den Fehler wieder zu bekommen.

[Codehunter]

Ich hatte ähnliche Fehlermeldungen immer mal wieder in meiner Anfangszeit mit TVirtualTreeView. Damals hatte ich das Konzept der Speicherverwaltung noch nicht ganz verstanden. Es kam immer wieder vor, dass ich dynamisch mit New(PRecord) erzeugte Records doppelt freigeben wollte (einmal mit FreeNode, einmal mit Dispose), was dann zu den eingangs beschriebenen Fehlern führte.