FastMM Memory Error Detected beim Debuggen

[TiGü]

Delphi-Quellcode:

---------------------------
X.exe: Memory Error Detected
---------------------------
FastMM has detected an error during a FreeMem operation. An attempt has been made to free/reallocate a block that was allocated through a different FastMM instance. Check your memory manager sharing settings.

The block size is: 18

This block was allocated by thread 0x818, and the stack trace (return addresses) at the time was:

20007117 [System.pas][System][System.@NewUnicodeString][18313]
200067E8 [System.pas][System][System.@UStrFromPWCharLen][17197]
2009E26F [Controls.pas][Controls][Controls.TControl.GetText][5554]
270036 
2005973A [StdCtrls.pas][StdCtrls][StdCtrls.TCustomCombo.Change][3570]
20059607 [StdCtrls.pas][StdCtrls][StdCtrls.TCustomCombo.CNCommand][3528]
2009FA05 [Controls.pas][Controls][Controls.TControl.WndProc][6642]
77608153 [RtlUnlockHeap]
77608153 [RtlUnlockHeap]
77608153 [RtlUnlockHeap]
77608153 [RtlUnlockHeap]

The block was previously used for an object of class: TChangeLink

The block is currently used for an object of class: Unknown

The allocation number is: 77689

The block was previously freed by thread 0x818, and the stack trace (return addresses) at the time was:

20004245 [System.pas][System][System.TObject.FreeInstance][9810]
200047B9 [System.pas][System][System.@ClassDestroy][10632]
200B0D18 [ImgList.pas][ImgList][ImgList.TChangeLink.Destroy][1555]
2000428B [System.pas][System][System.TObject.Free][9829]
2005B9AE [StdCtrls.pas][StdCtrls][StdCtrls.TCustomButton.Destroy][4796]
200A146C [Controls.pas][Controls][Controls.TWinControl.Destroy][7737]
200B69B5 [Forms.pas][Forms][Forms.TScrollingWinControl.Destroy][2644]
200B78EE [Forms.pas][Forms][Forms.TCustomForm.Destroy][3246]
2000428B [System.pas][System][System.TObject.Free][9829]
200BCC25 [Forms.pas][Forms][Forms.TCustomForm.CMRelease][6249]
2009FA05 [Controls.pas][Controls][Controls.TControl.WndProc][6642]

The current thread ID is 0x818, and the stack trace (return addresses) leading to this error is:

405789 [System.pas][System][System.@LStrFromPWCharLen][14467]
270036 
2005973A [StdCtrls.pas][StdCtrls][StdCtrls.TCustomCombo.Change][3570]
20059607 [StdCtrls.pas][StdCtrls][StdCtrls.TCustomCombo.CNCommand][3528]
2009FA05 [Controls.pas][Controls][Controls.TControl.WndProc][6642]
77608153 [RtlUnlockHeap]
77608153 [RtlUnlockHeap]
77608153 [RtlUnlockHeap]
77608153 [RtlUnlockHeap]
765E491D [LocalUnlock]
765E4933 [LocalUnlock]

Current memory dump of 256 bytes starting at pointer address 7EE676F0:

B0 04 02 00 00 00 00 00 02 00 00 00 31 00 32 00 00 00 17 10 FB 42 80 80 00 00 00 00 D0 14 E6 7E
00 00 00 00 00 00 00 00 F4 CD 00 20 00 00 00 00 A5 1F 01 00 4E 33 00 20 27 42 00 20 6E 47 00 20
5C 42 00 20 D1 B3 02 20 23 C7 09 20 4D 26 0A 20 01 27 0A 20 91 E1 09 20 E2 82 0A 20 E5 D1 09 20
18 08 00 00 18 08 00 00 6A 33 00 20 F0 83 00 20 97 BF 01 20 31 BF 01 20 96 23 03 20 6F 17 03 20
A6 11 03 20 E2 82 0A 20 88 11 03 20 4A D4 09 20 BA 15 0A 20 14 00 00 00 00 00 00 00 01 74 57 5F
90 85 02 20 B0 70 E6 7E 02 00 00 00 04 00 00 00 00 00 00 00 FE 8B A8 A0 00 00 00 00 D0 14 E6 7E
00 00 00 00 00 00 00 00 F4 CD 00 20 00 00 00 00 B0 D2 00 00 4E 33 00 20 17 71 00 20 E8 67 00 20
CA 6E 00 20 3B 2E 01 20 1D 3D 10 20 85 07 1F 20 D2 18 89 76 12 BF 1E 20 D6 F1 10 20 4A F6 10 20

°  .  .  .  .  .  .  .  .  .  .  .  1  .  2  .  .  .  .  .  û  B  €  €  .  .  .  .  Ð  .  æ  ~
.  .  .  .  .  .  .  .  ô  Í  .     .  .  .  .  ¥  .  .  .  N  3  .     '  B  .     n  G  .   
\  B  .     Ñ  ³  .     #  Ç  .     M  &  .     .  '  .     ‘  á  .     â  ‚  .     å  Ñ  .   
.  .  .  .  .  .  .  .  j  3  .     ð  ƒ  .     —  ¿  .     1  ¿  .     –  #  .     o  .  .   
¦  .  .     â  ‚  .     ˆ  .  .     J  Ô  .     º  .  .     .  .  .  .  .  .  .  .  .  t  W  _
�  …  .     °  p  æ  ~  .  .  .  .  .  .  .  .  .  .  .  .  þ  ‹  ¨  *  .  .  .  .  Ð  .  æ  ~
.  .  .  .  .  .  .  .  ô  Í  .     .  .  .  .  °  Ò  .  .  N  3  .     .  q  .     è  g  .   
Ê  n  .     ;  .  .     .  =  .     …  .  .     Ò  .  ‰  v  .  ¿  .     Ö  ñ  .     J  ö  .   
---------------------------
OK   
---------------------------

Ich habe seit einigen Tagen den externen FastMM installiert.

Wenn ich während des debuggens per MouseOver den Inhalt eines TCombobox.Text sehen will oder auch per Evaluate/Modify-Fenster entsprechende Property evaluieren will, kommt oben stehende Fehlermeldung.
Trotz jener Fehlermeldung, steht im Evaluate/Modify-Fenster der richtige Wert.

Anfangs steht ja: "Check your memory manager sharing settings".
Auf was soll ich da mein Augenmerk richten?

Der zweite Call Stack ("The block was previously freed...") ist auch jedes Mal anders. Ebenso die Block Size am Anfang der Fehlermeldung!

[Bernhard Geyer]

Was meinst du mit installiert? In der IDE installiert oder im Programm eingebunden?

[TiGü]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1177355)

Was meinst du mit installiert? In der IDE installiert oder im Programm eingebunden?

So:
http://stackoverflow.com/questions/1...ce-from-fastmm

Zitat:

The internal Delphi version of FastMM doesn't support stack traces.

If you want to log the memory leak stack traces, you have to:

download the FastMM library
include it as the first unit in your project:

program YourProject;
uses
FastMM4,
SysUtils,
Forms,
...

enable the FullDebugMode in FastMM4Options.inc
set Map file to Detailed in the linking project options (the FastMM_FullDebugMode.dll processes the .map file)
add the FastMM_FullDebugMode.dll in your binary (or Windows System32) directory

Und in allen DPRs gleich nach dem begin ReportMemoryLeaksOnShutdown := DebugHook <> 0; reingeschrieben.
Zum Konfigurieren der FastMM4Options.inc habe ich den GUI-Editor von Jeremy North genutzt.

[TiGü]

Es scheint generell ein Problem für Instanzen mit String-Properties zu sein.
Es tritt ständig auf.
Ich halte den Mauszeiger über entsprechende Property, es kommt kurz als Hint "Evaluate..." und dann kommt die bildschirmfüllende Meldung.

[TiGü]

Hätte denn jemand eine Idee, welche FastMM-Option eingestellt werden müsste, um dieses schon recht nervige Verhalten abzustellen?

[Iwo Asnet]

Zitat:

An attempt has been made to free/reallocate a block that was allocated through a different FastMM instance. Check your memory manager sharing settings.

Irgendwas is da doppelt bei Dir, z.B. verschiedene FastMM-DLL in den Verzeichnissen, oder Du verwendest selber DLLs etc.

[himitsu]

Es kann auch sein, daß unter den zwei betroffenen Modulen (EXE und/oder DLLs) das sharing für FastMM nicht aktiv ist,
aber dennoch Speicher (Strings, Objekte usw.) übergeben werden und der andere FastMM dann versucht das freizugeben, was ihm garnicht gehört.

[TiGü]

Es handelt sich um eine Anwendung, die ein Formular aus einer DLL öffnet/kreiert.
Natürlich werden dafür auch mehrere Informationen weitergereicht.

Jedoch tritt der Fehler auch bei String-Propertys der Formular-Komponenten auf (TComboBox etc.).

Im Verzeichnis wo betreffende EXE und DLL liegen, sind nur die FastMM_FullDebugMode.dll und sein 64-Bit Bruder kopiert.
Im Windows/System32 liegt keine FastMM-DLL.

Muss ich noch irgendetwas besonderes einstellen?
In beiden Projekten (gehören auch zu einer Projektgruppe) ist FastMM auf gleicher Weise aktivert.

[himitsu]

Das heißt du erstellst in der DLL eine Form-Instanz und gibst diese dann an die EXE weiter?

Sowas macht man nicht, :!:
denn EXE und DLL haben (standardmäßig) nicht nur unabhängige Speichermanager (abgesehn von ShareMem und Co.), sondern auch, und vorallem das, getrennte/eigenständige RTTIs.

Die andere Variante wären Laufzeitpackages, bei welchen auch die RTTI mit gemeinsam verwendet wird.



Du kannst ein Interface in der DLL bereitstellen, welches für die Kontrolle der Form zuständig ist, aber Objekte sollten tunlichst nicht die DLL/EXE-Grenze überschreiten.
Und auch sowas wie Strings (ausgeschlossen ShortString, WideString, PChar und statische Char-Arrays) sollten ohne Shared Memory nicht diese Grenze überschreiten.

[TiGü]

Zitat:

Zitat von himitsu (Beitrag 1177554)

Das heißt du erstellst in der DLL eine Form-Instanz und gibst diese dann an die EXE weiter?

Nein, sowas natürlich nicht! :roll:
Ich mache es richtig und übergebe der DLL ein PAnsiChar.

Zur besseren Veranschaulichung habe ich eine Beispielprojektgruppe mit Delphi 2009 erstellt.
Im angehängten ZIP bitte die Projektgruppe öffnen.
Es ist ein Programm nebst DLL.

In den Projekt-Einstellungen beider Projekte die Werte für Output directory, Working directory, Host application und Unit output directory entsprechend eurer Konfiguration anpassen.
Ich arbeite hier mit Umgebungsvariablen.

Auch müsst ihr ggf. den Ort der FastMM4.pas anpassen, der wird bei mir über die Tools->Options->Delphi Options-> Library - Win32 vererbt.
Die entsprechenden FastMM4-DLLs nicht vergessen.

DLL als Startprojekt:
In der DLL den Breakpoint nach der Stelle setzen, wo die DLL-Frm den neuen Caption-String erhält (DLLMain - Zeile 22).
Sobald das Programm hier anhält, bitte die Maus über die Property Caption von DLLFrm.lbl1.Caption halten.
Normalerweise erscheint dann dort dann der entsprechende String, mit FastMM4 eine Fehlermeldung (siehe Screenshot im Anhang).

Merkwürdigerweise kann man einen Debug-Hint erhalten, wenn man auf lbl1 geht und dort über TControl nach FText sucht.
Hier steht's dann richtig drin.

Es ist irgendwie so, als ob FastMM4 nicht mit GetText von der Caption-Property zurecht kommt.

Kann jemand mein Problem nachvollziehen?

[Iwo Asnet]

Benutzen den Delphi und deine Anwendung die gleiche FastMM-Instanz?

[TiGü]

Zitat:

Zitat von Iwo Asnet (Beitrag 1177727)

Benutzen den Delphi und deine Anwendung die gleiche FastMM-Instanz?

Meinst du das:

EXE und DLL greifen auf die gleiche FastMM4.pas/-.dcu zu und auch natürlich auf die gleiche FastMM_FullDebugMode.dll (EXE und DLL liegen auch im gleichen Verzeichnis).

[TiGü]

Ich zweifle langsam an mir?!
Entweder FastMM hat nen schweren Bug oder die VCL-Sourcen haben nen Sprung.

Beispielprogramm OHNE DLL Beteiligung im Anhang (mit FastMM_FullDebug.dll).

Delphi-Quellcode:

procedure TMainForm.Test;
var
 str : string;
begin
  str :=  edt1.Text;
  lbl1.Caption := str;
end;

Wenn ich hier reindebugge und per MouseOver mir die Werte für edt1.Text und für lbl1.Caption im Debug-Hint anzeigen lasse, bekomme ich beim Beenden einen Memory Leak Report für 2 x UnicodeStrings:

Code:

--------------------------------2012/8/10 16:15:27--------------------------------
A memory block has been leaked. The size is: 68

This block was allocated by thread 0x12E4, and the stack trace (return addresses) at the time was:
40618B 
405894 
4493CF [Controls.pas][Controls][Controls.TControl.GetText][5554]
20036 
46C6CC [Main.pas][Main][Main.TMainForm.btn1Click][39]
44B049 [Controls.pas][Controls][Controls.TControl.Click][6758]
438903 [StdCtrls.pas][StdCtrls][StdCtrls.TCustomButton.Click][4421]
439371 [StdCtrls.pas][StdCtrls][StdCtrls.TCustomButton.CNCommand][4858]
44AADD [Controls.pas][Controls][Controls.TControl.WndProc][6642]
760525A8 [NotifyWinEvent]
76072FCA [Unknown function at SetKeyboardState]

The block is currently used for an object of class: UnicodeString

The allocation number is: 650

--------------------------------2012/8/10 16:15:27--------------------------------
A memory block has been leaked. The size is: 68

This block was allocated by thread 0x12E4, and the stack trace (return addresses) at the time was:
40618B 
405894 
4493CF [Controls.pas][Controls][Controls.TControl.GetText][5554]
20036 
46C6CC [Main.pas][Main][Main.TMainForm.btn1Click][39]
44B049 [Controls.pas][Controls][Controls.TControl.Click][6758]
438903 [StdCtrls.pas][StdCtrls][StdCtrls.TCustomButton.Click][4421]
439371 [StdCtrls.pas][StdCtrls][StdCtrls.TCustomButton.CNCommand][4858]
44AADD [Controls.pas][Controls][Controls.TControl.WndProc][6642]
760525A8 [NotifyWinEvent]
76072FCA [Unknown function at SetKeyboardState]

The block is currently used for an object of class: UnicodeString

The allocation number is: 656

--------------------------------2012/8/10 16:15:27--------------------------------
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

53 - 68 bytes: UnicodeString x 2

Note: This memory leak check is only performed if Delphi is currently running on the same computer. Memory leak detail is logged to a text file in the same folder as this application. To disable this memory leak check, undefine "EnableMemoryLeakReporting".

[DeddyH]

Dieses Verhalten von FastMM kenne ich aber auch: ReportMemoryLeaksOnShutdown auf true, Breakpoint gesetzt, Leaks werden gemeldet. Breakpoint entfernt, Leaks verschwinden. Woran das liegt, wüsste ich auch gern.

[Furtbichler]

Wäre es denkbar, das Delphi zum Debuggen/Anzeigen Speicher über FastMM anfordert, aber nicht freigibt, wenn die Anwendung beendet ist, sondern entweder später oder eben überhaupt nicht?

[DeddyH]

Ausschließen würde ich das nicht.

[TiGü]

Schade, dass das Thema auf kein Interesse stößt. :(

Verwendet denn sonst keiner FastMM4 und kennt dieses Problem und eine mögliche Lösung?

Im Anhang nochmal das ursprüngliche Beispielprojekt als ZIP-Archiv.
Ich habe es so angepasst und mit allen notwendigen Dateien versehen, dass man es nur noch runterladen, entpacken, Projektgruppe öffnen und beide Projekte erzeugen muss.

Es wäre einfach nur nett, wenn jemand seine IDE anwerfen könnte und das Problem nachvollzieht.
Hier zuhause habe ich es auch mit dem RAD Studio XE erlebt.

Vielleicht hätte ich auch einen reißerischen Titel wählen sollen!
So à la "Brauche Hilfe um diesen String auseinanderzubasteln" oder "In welche Ecke der Form gehört die visuelle Datenbank-Komponente"...:cry:

Übrigens funktioniert der Debug-Hint per MouseOver, wenn man den FullDebugMode auschaltet, aber ohne ist ja FastMM4 ohne wirkliche Funktion.

[haentschman]

Habe es malprobiert...
Die Hints werden mit den richtigen Werten angezeigt (Caption,Text). Nach Beendigung...

Zitat:

---------------------------
TheProgram.exe: Memory Leak Detected
---------------------------
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):



21 - 36 bytes: UnicodeString x 1



Note: Memory leak detail is logged to a text file in the same folder as this application. To disable this memory leak check, undefine "EnableMemoryLeakReporting".


---------------------------
OK
---------------------------

Bei Beenden ohne Breakpoint kein Leak.

... interessantes Ding das. :roll:

[himitsu]

Stell doch erstmal dein FastMM ordentlich ein.

Speziell folgende Punkte sehn nicht so gut aus:

Zitat:

Zitat von deine FastMM4Options.inc

Delphi-Quellcode:

{.$define ShareMM}

{.$define ShareMMIfLibrary}

{.$AttemptToUseSharedMM}

{Define this to enable backward compatibility for the memory manager sharing
 mechanism used by Delphi 2006 and 2007, as well as older FastMM versions.}
{$define EnableBackwardCompatibleMMSharing}

Wenn dir der interne FastMM ausreichent, dann verwende einfach die SimpleShareMem.pas .


[add]
Wenn ich das

Delphi-Quellcode:

ReportMemoryLeaksOnShutdown := DebugHook <> 0;

in der EXE weglasse, dann gibt es keine Meldung. (XE2-Win32)
Vermutlich hängt sich hier der Debugger an den Speichermanager in der EXE, obwohl du eigentlich den der DLL nutzt.

Wenn ich das richtog gesehn hab, gibt es ein Problem in der SysUtils, wo nachdem beide MemoryManager freigegeben wurden noch versucht wird ein String freizugeben.
Probier mal was passiert, wenn du die Init-Initialisationsreihenfolge nicht durcheinanderbringst und in der DLLMain das

Delphi-Quellcode:

uses MyForm;

in das Interface verschiebst.

[TiGü]

Zitat:

Zitat von himitsu (Beitrag 1177980)

Stell doch erstmal dein FastMM ordentlich ein...

Weder das Entfernen des ReportMemoryLeaksOnShutdown-Flags, noch das Verschieben der Uses-Klausel führten zum Erfolg.
Jedoch ist der Hinweis die Optionen ShareMM, ShareMMIfLibrary und AttemptToUseSharedMM zu aktivieren die Lösung!
Vielen Dank dafür!
Es müssen auch alle drei Optionen aktiviert sein.
Wenn eine fehlt, kommt es weiterhin zu dem Fehler.

Aber warum ist das so? Ich würde es gerne verstehen!
Wo kann ich mich genauer über das Thema Memory Manager informieren?
Die Doku von Emba ist etwas nichtssagend in der Hinsicht, oder aber ich finde nicht die richtigen Einträge im Wiki dazu.
Hat jemand weiterführende Lektüre?

[himitsu]

Bei Emba wirst du da nichts finden, denn dort ist eine "andere/spezielle Version" des FastMM integriert, welche nicht über diese INC gesteuert wird. (dort kann man aber über units wie SimpleShareMem sehr einfach vordefinierte Einstellungen für das Sharing nutzen)

Zu ShareMM, ShareMMIfLibrary und AttemptToUseSharedMM sollte was in der INC stehn und früher fand man auch Mal ein paar Infos auf der Webseite von Pierre le Riche, welche FastMM entwickelt hatte.

[TiGü]

Zitat:

Zitat von Aus_der_INC-Datei

{-----------------------Memory Manager Sharing Options------------------------}

{Allow sharing of the memory manager between a main application and DLLs that
were also compiled with FastMM. This allows you to pass dynamic arrays and
long strings to DLL functions provided both are compiled to use FastMM.
Sharing will only work if the library that is supposed to share the memory
manager was compiled with the "AttemptToUseSharedMM" option set. Note that if
the main application is single threaded and the DLL is multi-threaded that you
have to set the IsMultiThread variable in the main application to true or it
will crash when a thread contention occurs. Note that statically linked DLL
files are initialized before the main application, so the main application may
well end up sharing a statically loaded DLL's memory manager and not the other
way around. }
{.$define ShareMM}

{Allow sharing of the memory manager by a DLL with other DLLs (or the main
application if this is a statically loaded DLL) that were also compiled with
FastMM. Set this option with care in dynamically loaded DLLs, because if the
DLL that is sharing its MM is unloaded and any other DLL is still sharing
the MM then the application will crash. This setting is only relevant for
DLL libraries and requires ShareMM to also be set to have any effect.
Sharing will only work if the library that is supposed to share the memory
manager was compiled with the "AttemptToUseSharedMM" option set. Note that
if DLLs are statically linked then they will be initialized before the main
application and then the DLL will in fact share its MM with the main
application. This option has no effect unless ShareMM is also set.}
{.$define ShareMMIfLibrary}

{Define this to attempt to share the MM of the main application or other loaded
DLLs in the same process that were compiled with ShareMM set. When sharing a
memory manager, memory leaks caused by the sharer will not be freed
automatically. Take into account that statically linked DLLs are initialized
before the main application, so set the sharing options accordingly.}
{.$define AttemptToUseSharedMM}

{Define this to enable backward compatibility for the memory manager sharing
mechanism used by Delphi 2006 and 2007, as well as older FastMM versions.}
{$define EnableBackwardCompatibleMMSharing}

Soweit ich das vorher verstanden hatte, sollte sich diese Option doch nur auswirken, wenn Arrays oder normale Strings übergeben werden (nicht WideString).

In meinen Fall wird jedoch richtigerweise ein Zeiger übergeben.

Ja, selbst wenn man das Beispiel so abändert, dass einfach nur das Formular aufgerufen wird (ohne irgendetwas an die DLL zu übergeben) erhält man ja den Fehler beim Zugriff auf String-Propertys des DLLFrm.

Auch beim Zugriff auf DLLFrm.Caption oder Ähnliches gibt es die gleichen Meldungen.
Debuggen von anderen Datentypen bereiten aber keine Probleme?!?

Die FAQ zu FastMM4 haben mich auch nicht schlauer gemacht.