![]() |
XE Memory Leak
Hallo alle... 8-)
eben bin ich fast durchgedreht. Ich suche seit gestern in meinem Quelltext ein Memory Leak von 1-12 Bytes (Unbekannt). Alles auskommentiert bis auf die nackige GUI... ohne Erfolg. Ressource neu erzeugt...usw. Dann habe ich die dproj neu erzeugt... und siehe da das Leak ist weg :thumb: Dachte ich... Dann habe ich die Einstellungen des Projektes wieder angepaßt. :shock: Da waren die 12 Bytes wieder da :shock: Ich habe herausgefunden: - sobald im Ausgabepfad .\$(Config)\$(Platform) steht gibt´s das Leak. Steht da ein anderer Pfad oder nix ist es gut. Kann das jemand nachvollziehen ? Danke. |
AW: XE Memory Leak
Wie sieht denn das entsprechende Log von FastMM aus? Also das ausführliche FullDebug-Log.
Bei mir treten auch mit diesem Ausgabeverzeichnis keine Leaks auf, ich kann das nicht reproduzieren. |
AW: XE Memory Leak
Soooo... :wink:
hat etwas gedauert... Zitat:
PS: ich bin nicht auf diesen Ordner angewiesen, da ich eh immer einen seperaten Ordner für das Compilat habe. Aber interressant ist das schon. |
AW: XE Memory Leak
Zitat:
Starte mal dein Programm und kurz vorm Beenden guckst du über den Debugger, in der CPU-Ansicht, ob du bei oder ein Stückchen vor den Adressen 40461E $0040A90D, $0040A8A8, $0040AC14 und $0040AD21 erkennen kannst was das für Funktionen sind. Eventuell auch je einen Haltepunkt darauf, dann beenden und erneut starten ... eventuell bleibt der Debugger dort hängen und zeigt dir einen ordentlichen Stacktrace. Notfalls alle möglichen Debuginfos an, Codeoptimierung aus, Stackframes an und mit Debug-DCUs kompilieren. (eventuell reicht auch schon Letzteres aus) Aber hier natürlich aufpassen, da sich da dabei die Codeadressen verändern könnten. PS: Selbst wenn du das Leak selber nicht wegbekommst, falls du zuverlässig rausbekommst wo dieses Leck liegt, kannst du es auch ignorieren lassen. (macht Indy auch nicht anders, mit seinen Löschern) |
AW: XE Memory Leak
Zitat:
In einem anderen Ausgabeordner als .\$(Config)\$(Platform) habe ich mit dem kompletten Quelltext (incl. Lokalisierung) kein Leak. Nachtrag: Es scheint so, wenn die Lokalisierung verantwortlich wäre, daß das Leak erscheint wenn die exe mit den dcu´s den Ordner teilt. Was aber unlogisch wäre. |
AW: XE Memory Leak
Die Delphi-RTL/VCL lokalsiert auch.
z.B. bei den Resourcen (du kennst bestimmt die .de-Dateien zu DLLs/BPLs und auch die Resourcen selbst sind sprachgebunden, seitens Windows) [edit] hatte oben noch was editiert |
AW: XE Memory Leak
Zitat:
Zitat:
|
AW: XE Memory Leak
Vor Sonntag werde ich wohl keine Zeit finden und dann muß ich mal sehn, ob ich den Fehler hinbekomm.
Zitat:
|
AW: XE Memory Leak
Dann kurz noch zur Erklärung:
Ich hatte mich mit Lokalisierung beschäftigt. Erstens Bordmittel. Projekt-> Sprachen usw. Dann habe ich Lingus probiert (von wicht aus der DP). Einfach und simpel. Die Sprachen wieder rausgeschmissen. Ich habe aber die dproj neu erzeugt, die dcu alle entfernt (Debug\Win32)... was man so halt macht. Ich kann das ganze reproduzieren. Bei jedem anderen Ordner als .\$(Config)\$(Platform) habe ich kein Leak. Ordnerstruktur: (- = Ordner) Project - Debug\Win32 (Leak) - Debug\1.0 (kein Leak) - Release\1.0 (wenn es soweit ist) - Language (res der Sprachen - Lingus) *.pas *.dpr . . . (bei Ausgabeordner leer und exe hier, kein Leak) usw. ...komisches Ding das :stupid: Nachtrag: - bei einem komplett neuem Projekt (Form1) ohne irgendwas, nur mit ReportMemoryLeaksOnShutdown, tritt dieser Effekt auf :gruebel: |
Alle Zeitangaben in WEZ +1. Es ist jetzt 03:25 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz