Wer mit der WinAPI andere Datentypen als Parameter benötigt, als Xbase++ standardmäßig anbietet,
sollte sich die OT4XB von Pablo ( http://www.xbwin.com ) ansehen.
In der aktuellen Version ot4xb_001_005_012_021.zip
wurde ein Speicherleck in den Call Routinen aufgedeckt und beseitigt, also dringend updaten !
Dieses Speicherleck wurde im Zusammenhang mit der QuickPDF Bibliothek erkannt.
Pablo hat eine wrapper Klasse geschrieben, die ich nutzen will aber bei vielen Aufrufen ging immer
Speicher verloren. Auch mit der neuen OT4XB - mit PowerBasic trat das Problem nicht auf.
Pablo hat es dann mit C++ getestet und auch dort verschwand bei jedem Aufruf Speicher.
Nach dem Programmende wurde aber immer alles wieder freigegeben.
Eine Einzelanwendung hätte damit leben können, aber ein Serverprogramm ...
Pablo fand dann den Unterschied. Die QuickPDF.DLL belegt bei jedem Laden (DllLOAD()) etwas Speicher
für seine internen Variablen. DllUNLOAD() gibt diesen aber nicht wieder frei (oder die DLL ? ) ...
Im PowerBasic Beispiel wurde die geladene Dll nie entladen und blieb im Speicher bis zum Programmende.
Und genau das ist auch für Xbase++ die Lösung !
Wenn man also nicht genau weiß warum, einfach DllUnload() nicht verwenden.
Eine DLL wird nie zweimal geladen, daher passiert nichts beim nächsten DllLoad() ...
PS: Pablo hat die TQuickPDF für QuickPDF 7.18 freigegeben und meine HB_QPDF (mit einigen eigenen Methoden) folgt bald.
OT4XB / DLLLOAD() und DLLUNLOAD() - Speicher Freigabe ?
Moderator: Moderatoren
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: OT4XB / DLLLOAD() und DLLUNLOAD() - Speicher Freigabe ?
Ich nutze einige Fremd-DLLs, aber mir ist noch keine untergekommen, bei der es Sinn gehabt hätte, sie fallweise zu laden und wieder zu "entladen". Also mache ich das beim Programmstart und sammle die Pointer in einem Array. Dann gibt's auch keine Probleme mit verbleibenden Speicherfragmenten. Um mit List&Label threadsafe umgehen zu können, geschieht es hier zusätzlich für jeden neuen Thread, da prinzipiell parallel gedruckt werden könnte (in der Realität geschieht das allerdings meines Wissens nicht - man müsste schon ganz schön flink sein, um in zwei Threads parallel Druckvorgänge auszulösen).
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: OT4XB / DLLLOAD() und DLLUNLOAD() - Speicher Freigabe ?
Warum weiß ich auch nicht, aber irgendwie dachte ich im Destroy meiner Klasse die DLL entladen zu müssenTom hat geschrieben:Ich nutze einige Fremd-DLLs, aber mir ist noch keine untergekommen, bei der es Sinn gehabt hätte, sie fallweise zu laden und wieder zu "entladen". Also mache ich das beim Programmstart und sammle die Pointer in einem Array. Dann gibt's auch keine Probleme mit verbleibenden Speicherfragmenten.
und Pablo tat es in seiner auch und schon hatten wir den Schlamassel ... daher die Info hier
Gruß
Hubert
Hubert
- Pablo Botella
- Rookie
- Beiträge: 14
- Registriert: Do, 18. Dez 2008 20:14
- Wohnort: Santiago de Compostela - Spain
- Kontaktdaten:
Re: OT4XB / DLLLOAD() und DLLUNLOAD() - Speicher Freigabe ?
Hallo,
Die Funktionen nFpCall(), ndFpCall() und qwFpCall() hatte diese Probleme nicht.
Aber es gibt eine Menge Verbesserungen, die in der geerbten Klasse, wodurch es einfacher und weitere nützliche getan werden kann.
Mehrere Lasten der DLL tut nichts, aber der Verweiszähler erhöht, so dass wenn Sie DllLoad() 2 Mal aufrufen die DLL nach Aufruf DllUnload() 2 Mal getrennt werden wird.
Im Fall von QuickPDF einige zugeordneten Ressourcen sind nur aufgegeben, wenn die DLL abgetrennt ist, aus der Proccess, so dass jedes Mal, wenn die QuickPDF-DLL erfolgreich getrennt und wieder an die Proccess angeschlossen ist die verlassenen Ressourcen nicht wiederverwendet werden, aber einen neuen Satz wieder Essen des Speichers zuweisen.
Grüße
Pablo Botella
.. Fortunatelly dies auftreten, nur in FpQCall() und delegated_FpQCall().brandelh hat geschrieben:wurde ein Speicherleck in den Call Routinen .
Die Funktionen nFpCall(), ndFpCall() und qwFpCall() hatte diese Probleme nicht.
Meine TQuickPdf war nur als einfachen Wrapper über die QuickPDF-DLL gedacht, die nur zusätzliche ist der Embeded-Unterstützung für binäre Zeichenfolgen (in der gleichen Weise, die auch, die bereitgestellten C++- und C#-Klassen tun). Making auf diese Weise, wenn die QuickPDF-DLL aktualisiert werden wird einfacher, die Wrapper auch aktualisieren.brandelh hat geschrieben:PS: Pablo hat die TQuickPDF für QuickPDF 7.18 freigegeben und meine HB_QPDF (mit einigen eigenen Methoden) folgt bald.
Aber es gibt eine Menge Verbesserungen, die in der geerbten Klasse, wodurch es einfacher und weitere nützliche getan werden kann.
In der Regel besteht kein Probleme zu laden/eine Dll entladen wenn nur die benötigten Ocasionally und die Dll loslässt, alle Ressourcen auf den Schritt trennen.Tom hat geschrieben:Ich nutze einige Fremd-DLLs, aber mir ist noch keine untergekommen, bei der es Sinn gehabt hätte, sie fallweise zu laden und wieder zu "entladen".
Mehrere Lasten der DLL tut nichts, aber der Verweiszähler erhöht, so dass wenn Sie DllLoad() 2 Mal aufrufen die DLL nach Aufruf DllUnload() 2 Mal getrennt werden wird.
Im Fall von QuickPDF einige zugeordneten Ressourcen sind nur aufgegeben, wenn die DLL abgetrennt ist, aus der Proccess, so dass jedes Mal, wenn die QuickPDF-DLL erfolgreich getrennt und wieder an die Proccess angeschlossen ist die verlassenen Ressourcen nicht wiederverwendet werden, aber einen neuen Satz wieder Essen des Speichers zuweisen.
Grüße
Pablo Botella