Entwickler-Ecke
Sonstiges (Delphi) - FastMM, FastShareMem und MadExcept in einer Anwendung?!?
rochus - Do 13.10.05 09:16
Titel: FastMM, FastShareMem und MadExcept in einer Anwendung?!?
Hi,
Ist es eigentlich irgendwie möglich, FastMM, FastShareMem und MadExcept oder so in Anwendungen zu kombinieren? Alle behaupten ja (außer bei MadExcept, da bin ich mir nicht sicher), sie müssten als erste unit in der Uses-Klausel des Projekts stehen... Angenommen ich hab eine Hauptanwendung, in der möchte ich FastMM nutzen. Da ich aus einer anderen Anwendung mit DLL sehr gute erfahrungen mit FastShareMem habe und in die FastMM-Anwendung jetzt eine DLL einbinden möchte, frage ich mich natürlich, ob das geht, oder wie ich das machen könnte.
Gruß
Lossy eX - Do 13.10.05 10:48
Ich denke mal, dass solche Bibliotheken die interne Speichererwaltung austauschen (2 oder 3 Methoden) und durch eigene Methoden ersetzen. Um Probleme mit anderen Units zu vermeiden müssen diese als erstes eingebunden werden. Da es sonst sein könnte, dass beereits Speicher mit dem ursrünglichen SpeicherManager angelegt wurde. Das ist der einzige Grund.
Wenn sich diese Bibliotheken nicht in die Quere kommen sollte das eigentlich kein Problem sein. Allerdings wenn jeder davon seine eigene Speicherverwaltung benutzt und die Ursprünglichen Methoden nicht mehr aufruft, dann dürfte lediglich die letzte Unit aktiv sein.
Ich denke mal, dass sich FastMM und FastShareMem in die Quere kommen. Rein von der Beschreibung her. Aber das würdesz du wohl erst herrasufinden, wenn du das selber mal ausprobierst. Ich denke auch mal, dass ist der einfachste und schnellste weg. Ich würde MadExcept da auf jeden Fall als dritterste Unit einbinden. Also nachdem die Speicherverwaltungen ausgetauscht wurden.
rochus - Do 13.10.05 14:45
Okay, hab da was gefunden. Wer lesen kann ist einfach immer noch im Vorteil:
| FastShareMem 2.10 Readme.txt hat folgendes geschrieben: |
USE OF FASTSHAREMEM WITH A LEAK DETECTOR
If you use a leak detector which also replaces the default
memory manager, include it immediately after FastSharemem
for all projects.
|
rochus - Do 13.10.05 15:38
Also das hat nicht geklappt. Ich hab dann jetzt mal die FastShareMem hinter die FastMM gestellt und alles scheint zu laufen. Hab aber noch eine Mail an die Jungs von CodeXterity geschrieben. Sobald eine Antwort kommt, antworte ich selbstverständlich hier.
rochus - Mo 17.10.05 16:08
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
| Hello,
Yes, that's correct. And that's a very good question. This shouldn't
cause any problems; in fact this is a way to make replacement memory
managers work with DLL's. With the old sharemem, you most likely lose
the functionality of the third-party manager.
Hope this helps, please don't hesitate to email me about FastSharemem
or anything else on the site.
On 10/13/05, Nicolai Waniek <rochus@rochus.net> wrote:
> Hello,
> I have a - maybe simple - question for which I do not find a good answer. As
> you suppose in the readme.txt, I should use FastShareMem as the very first
> unit within my project, and after that some memory manager replacement. Doing
> it this way, I get an exception from FastMM that it couldn't install itself
> because another Memory Manager was already installed. When changing the
> sequence to
>
> <div class="syntaxContainer"> <div class="syntaxTitle genmed"> <b>Quelltext</b> </div> <div class="syntax"> <table cellspacing="0" cellpadding="0"> <tr> <td valign="top" style="text-align: right; padding-right: 3px; border: #DBE4EB solid; border-width: 0px 1px 0px 0px;"> <pre>1:
2:
3:
4:
5:
</pre> </td> <td valign="top" style="width: 100%; padding-left: 3px;"> <pre class="sourcecode">> uses
> FastMM4,
> FastShareMem,
> ...
> </pre> </td> </tr> </table> </div></div>
>
> there is no warning thrown (though it would as i saw within FastShareMem.pas.
> So is this supposed to be the right way?
>
> Thanks in advance,
> Nicolai Waniek |
BenBE - Mo 17.10.05 18:28
Sowohl FastMM als auch FastShareMem prüfen bei der Initialisierung, das noch kein Speichermanager gesetzt ist. Um dies zu umgehen, müsstest Du beide etwas modifizieren, um diesen Fehler zu umgehen.
Ein Speichermanager, der Dir jegliche Alloc- und Dealloc-Meldungen ausgibt wäre z.B.
ODbgMemory.pas [
http://viewcvs.omorphia.de/omorphia/library/source/ODbgMemory.pas] (der als letzter) der Speichermanager-Folge einfach eingehängt wird. Er hookt einfach nur jegliche Speicher-Anforderungen und protokolliert diese. Die Funktionen für Leak-Detection müsste man dann aber selbstverständlich selbst programmieren. (Da der aber Arschlahm und rein aus Gaudi entstanden ist --> Finger weg!!!)
Allerdings sehe ich nicht, warum Du neben FastMM noch einen Leak-Detector brauchst: FastMM bietet diese Möglichkeiten bereits. Dazu musst Du einfach in deren Unit eine Direktive entsprechend abändern (FULLDEBUGMODE). Ist diese gesetzt, meldet er sich beim Beenden mit einer Exception, wenn reservierte Blöcke nicht freigegeben wurden ...
AndyB - Di 18.10.05 21:48
FastMMM enthält macht zusätzlichen auch das, was "FastShareMem" erledigt. Man muss nur die Compiler-Direktive ShareMM aktivieren.
rochus - Mi 19.10.05 12:56
Die hatte ich in der Zwischenzeit auch entdeckt, ja ;)
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!