FastMM Memory Error Detected beim Debuggen

[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 von himitsu:

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

Nein, sowas natürlich nicht!
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 von Iwo Asnet:

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).