SetDelimitedText Memory Leak ?

[himitsu]

Schade, das wäre eine einfache Erklärung gewesen, da globale Variablen in der DPR erst entladen werden, nachdem der Speichermanager aufgeröumt wurde.

Zitat von venice2:

Gebe ich einen normalen String ein so wie die @DieDolly habe ich das problem auch nicht.

"normale" String-Konstanten liegen nicht im Speichermanager. (die werden dierect aus dem Code verlinkt, mit ReferenceCounter = -1)


TStringList nutzt intern ein dynamisches Array mit den Strings der Zeilen,
da hätte ein Fehler schon lange auffallen müssen,
und im Setter des DelimitedText sollten die temporären Strings für das Zerlegen eigentlich auch automatisch aufgeräumt werden.

[venice2]

Ich habe es mit 2 Varianten versucht.
1 mal mit TStringList und einmal von Hand (also eigene Split Funktion)
Bei beiden funktioniert es nicht.
Stehe irgendwie auf dem Schlauch na gut ist halt so.

Seltsam ist nur das ich mit reinen Strings arbeite also keine Konvertierung von PWideChar, WideString oder der gleichen.
Trotzdem

Zitat:

Dann poste doch mal deinen kompletten code, dann kann man dir sicherlich besser helfen.

Den Quelltext hier zu posten bringt nichts da zu viele externe Funktionen aufgerufen werden die hier so niemand nachvollziehen kann.
Am ende gebe ich alles frei wie schon gezeigt aber die Leaks bleiben bestehen.

[hoika]

Hallo,
dann brauche wir ein compilierfähiges Minimalprojekt, also:
- leeres Projekt anlegen
- eine neue Unit (ohne DFM) anlegen
- deinen Code dort rein und in der DPR aufrufen.

Dann alles in eine Zip-Datei und hier hochladen (ohne die Exe).

[venice2]

Zitat von hoika:

Hallo,
dann brauche wir ein compilierfähiges Minimalprojekt, also:
- leeres Projekt anlegen
- eine neue Unit (ohne DFM) anlegen
- deinen Code dort rein und in der DPR aufrufen.

Dann alles in eine Zip-Datei und hier hochladen (ohne die Exe).

Danke für das Angebot.
Ich weis das es manchmal nötig ist Quelltexte zur Verfügung zu stellen aber ich sagte schon das bringt nichts ich kann es als Minimal Beispiel nicht auslegen.
Von daher wird mir wohl niemand helfen können muss mich da wohl selber durchbeißen.

[himitsu]

Zitat von venice2:

Den Quelltext hier zu posten bringt nichts da zu viele externe Funktionen aufgerufen werden die hier so niemand nachvollziehen kann.

Joar, eine kleine Testanwenndung, mit nur dem Wichtigsten, würde schon reichen.

[p80286]

Zitat von venice2:

Den Quelltext hier zu posten bringt nichts da zu viele externe Funktionen aufgerufen werden die hier so niemand nachvollziehen kann.
Am ende gebe ich alles frei wie schon gezeigt aber die Leaks bleiben bestehen.

Wenn der bekannte Code keine Fehler produziert, Deiner hingegen schon, woran könnte das dann liegen?

Gruß
K-H

[hoika]

Hallo,

Zitat:

Am ende gebe ich alles frei.

Das sieht halt Delphi anders...

1.
Wenn es kein schleichender "Programm verbraucht immer mehr Speicher"-Fehler ist
-> ignorieren, Windows räumt ja eh auf

2.
Sollte es Punkt 1 sein, hilft hier nur radikal
- alle Aufrufe totlegen
- Programm starten, testen
- ersten Aufruf reinnehmen, testen

usw.

Das mussten wir bei uns schon öfters machen.
Was dann bei "altem, bewährten, war schon immer so Code" rauskaum, poste ich lieber nicht

[TurboMagic]

Ist denn 100% sicher was da leakt?
Evtl. nämlich mal mit der vollen fastMM4 Version den Leakreport durchführen lassen,
denn der kann einem auch zeigen wo der Speicher allokiert wurde.
Evtl. leakt ja was anderes als gedacht.

Wobei ich mich da schon immer fragte, waru7m bei Delphi nicht diese volle Version
dabei ist, wenn die doch auch OpenSOurce ist...

[haentschman]

Moin...

Zitat:

Evtl. leakt ja was anderes als gedacht.

+1 Denke ich auch.

[venice2]

Zitat von TurboMagic:

Ist denn 100% sicher was da leakt?
Evtl. nämlich mal mit der vollen fastMM4 Version den Leakreport durchführen lassen,
denn der kann einem auch zeigen wo der Speicher allokiert wurde.

Die frage ist was kann FastMM was EurekaLog nicht kann?

Zitat:

+1 Denke ich auch.

Denken ist so eine Sache.