Wie kann man ein "halbes" Memory-Leak finden?

[Phoenix]

Hi,

ja, der Titel sagt es schon aus: Ich suche ein Memory-Leak, das nur halb eines ist.

Das Problem: Läuft die Anwendung, wächst der Speicher mit der Zeit ins Uferlose. Schliesse ich die Anwendung wird aber z.B. laut Eureka-Log der Speicher wieder vollständig freigegeben.

Ergo: Der gesamte angeforderte Speicher wird beim Beenden der Anwendung auch wieder freigegeben, irgendwo fragt die Anwendung allerdings mehr oder weniger regel- bzw. unregelmässig nach Speicher an und behält diesen, obwohl ich mir ziemlich sicher bin, dass sie diesen Speicher eigentlich schon viel Früher wieder freigeben könnte / müsste.

Das wäre an und für sich kein Problem, würde die Anwendung nur 8 Stunden am Tag genutzt dann beendet / am nächsten Tag neu gestartet. Blöderweise läuft diese Anwendung aber zumindest theoretisch 24/7/52. In der Praxis kachelt sie aufgrund mangels Speicher irgendwann ab.

Wie kann ich also so ein 'halbes' Speicherloch gezielt finden?

Ich hab echt keine Idee ausser den _gesamten_ Source durchzusehen, und an _jeder_ Stelle wo Speicher angefordert und freigegeben wird eine Ausgabe zu loggen. Nur ist der gesamte Source verdammt groß und das würde Ewigkeiten dauern. Gibts da einen besseren Ansatz?

[tomsel]

Hast du es schon mal mit MemProof o.Ä. versucht?

[Bernhard Geyer]

Ich vermute mal das du hier eine Komponenten so erzeugst das der Parent für die Freigabe verantwortlich ist.
Und anstatt das schon die vorhandene Instanz verwendet wird, wird jedesmal eine neue erzeugt.

[Dax]

Zitat von Phoenix:

Nur ist der gesamte Source verdammt groß und das würde Ewigkeiten dauern. Gibts da einen besseren Ansatz?

Jup, einen Proxy-MM. Du bastelst dir einen eigenen Memory Manager, der nichts weiter tut, als Re-/De-/Allokationen zu loggen und dann alle Aufrufparameter an den ursprünglichen MM weiterzureichen.

[Phoenix]

Zitat von tomsel:

Hast du es schon mal mit MemProof o.Ä. versucht?

Zitat von Phoenix:

Schliesse ich die Anwendung wird aber z.B. laut Eureka-Log der Speicher wieder vollständig freigegeben.

[Phoenix]

Zitat von Dax:

Jup, einen Proxy-MM. Du bastelst dir einen eigenen Memory Manager, der nichts weiter tut, als Re-/De-/Allokationen zu loggen und dann alle Aufrufparameter an den ursprünglichen MM weiterzureichen.

Im Prinzip also genau das, was Eureka-Log schon tut. Der matcht die halt am Ende gegeneinander und gibt das nicht aus.

Hast Du irgendwie einen Ansatz, was für ein Aufwand das wäre sowas zu schreiben? Insbesondere wenn man (wie ich) keinen Plan davon hat wie man sich in das Memory-Management einhängt?

Edit: Verklickt...

[Sherlock]

Es ist kein Memory-Management Problem...so wie ich das verstehe, sondern ein algorithmisches. Da werden Objekte erzeugt, die ja am Ende korrekt freigegeben werden. Nur werden die Objekte eigentlich nicht benötigt. Oder vielleicht nur kurzfristig, und werden viel zu spät freigegeben.

sherlock

[DMW]

Man munkelt, FastMM könne so etwas.

[Phoenix]

Zitat von Sherlock:

Es ist kein Memory-Management Problem...so wie ich das verstehe, sondern ein algorithmisches. Da werden Objekte erzeugt, die ja am Ende korrekt freigegeben werden. Nur werden die Objekte eigentlich nicht benötigt. Oder vielleicht nur kurzfristig, und werden viel zu spät freigegeben.

Genau das habe ich ja in meinem OP vermutet.

Nur: Wie findet man diesen Fehler?

[Sherlock]

Algorithmisches findet man eigentlich nur durch Analyse der Algorithmen. Das bedeutet je nach vorhandenener Dokumentation schlimmstenfalls ein Codewalkthrough

Sherlock