SetDelimitedText Memory Leak ?

[haentschman]

Moin...:P

Zitat:

Evtl. leakt ja was anderes als gedacht.

+1 :thumb: Denke ich auch.

[venice2]

Zitat:

Zitat von TurboMagic (Beitrag 1459317)

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.

[bernau]

Zitat:

Zitat von venice2 (Beitrag 1459365)

Die frage ist was kann FastMM was EurekaLog nicht kann?

Probier es doch einfach mal aus.

Zitat:

Zitat von venice2 (Beitrag 1459365)

Denken ist so eine Sache.

Sehr unfreundliche Antwort an jemanden der nur eine bestimmte These unterstützt.

[venice2]

Zitat:

Probier es doch einfach mal aus.

Es war eine Feststellung.
Ich verwende EurekaLog und das kann mindestens das was FastMM ebenfalls kann.
Es ist mir bekannt was den Leak verursacht nur ich kann ihn nicht beheben.

Zitat:

der nur eine bestimmte These unterstützt.

Das kann man auslegen wie einem gefällt.
Für mich hört es sich so an das der Dumme wie immer hinter der Tastatur sitzt.
Mit Thesen hat das nichts zu tun.

[himitsu]

Nja, es kommt drauf an, was/wieviel Embarcadero damals von Pierre gekauft hatte.
Und man hätte da dann noch so Einiges mehr umbauen müssen, also die ganzen Settings weg von Options-INC+IFDEF hin zu Variable/Parameter+IF-THEN,
denn die System-Unit neu zu kompilieren, nur um die Optionen zu ändern, geht nicht so gut.

Beim Debuggen ist Eurekalog das Schlimmste, was ich mir vorstellen kann (leidliche Erfahrung, wenn man bei Debuggen im Code/Assembler dessen Hooks landet und nicht mehr raus kommt)
und effektiv ist das Einzige, was wir beim Kunden wirklich zur Laufzeit nutzen, der Stacktrace und dafür müsste sich das Ding nicht so dermaßen penetrant überall reinhacken.



Für's Debugging gab es noch eine andere Memory-Debug-Komponente, die auch den Ersteller und die Zeit zu den Speicherblocks speichert/loggt und somit sagen kann von wem der Speicher "ursprünglich" stammt, welcher übrig bleibt,
bzw. wer zuerst den einen Speicher/Objekt freigab, wenn später nochmal jemand das machen will.

[haentschman]

Zitat:

Das kann man auslegen wie einem gefällt.

...und du hast es falsch ausgelegt. :?

Zitat:

Evtl. leakt ja was anderes als gedacht.

...war niemals auf dich bezogen sondern auf ein anderes Objekt in einem anderem Kontext. :roll: Wenn du dir den Schuh anziehst...

[venice2]

Zitat:

Zitat von haentschman (Beitrag 1459410)

Zitat:

Das kann man auslegen wie einem gefällt.

...und du hast es falsch ausgelegt. :?

Zitat:

Evtl. leakt ja was anderes als gedacht.

...war niemals auf dich bezogen sondern auf ein anderes Objekt in einem anderem Kontext. :roll: Wenn du dir den Schuh anziehst...

Dann tut es mir leid wenn ich das falsch aufgefasst habe.
Alles gut.

[haentschman]

:cheers: ...Biergarten.

[KodeZwerg]

Da wenig input kommt an denen man was erkennen könnte würde ich hoika's vorschlag mir zu herzen nehmen, auch wenn es je nach vielfalt des kodes lange dauern könnte.

Zitat:

Zitat von hoika (Beitrag 1459316)

- alle Aufrufe totlegen
- Programm starten, testen
- ersten Aufruf reinnehmen, testen

/ot
Hier ist auch ein EurekaLog Nutzer, mir gefällts, zum debuggen deaktivier ich's und hab null hooks
/ot

[himitsu]

Problem ist bei knapp 100 DLLs/BPLs, ist das irgendwo auch nur einen Hauch drin, schießt Eurekalog das ganze Programm ab,
anstatt nur eine Meldung auszugeben "keine Dedubinfos gefunden", kommt die Meldung und dann ein TerminateProcess.

Außerdem pfuscht der ECC an den Projektoptionen rum und zerballert die Debuginfos vom Delphi (klar, der hat ja seine eigenen "Besseren" und braucht den Rest nicht mehr), wodurch bei vielen Packages im Debugger oft keine Variablen aufgelöst werden können.