ZFX + Developia

Hallo,


ich habe ein kleines Programm geschrieben und wenn ich es laufen lasse, dann geht speicher verloren. Ich benutze "Visual Leak Detector" um die entsprechenden Stelle(n) zu finden. Dieser zeigt aber keines Leaks an. Wenn ich testweise ein new char[100]; mache, dann zeigt er dies an. Die Einbindung ist also richtig. Auch _Crt - Functions melden keine Speicherleaks. Da einige Strukturen verschiedene Buffer von DirectX allozieren habe ich testweise an verschiedenen Stellen einen debug report angefordert, aber auch hier stimmen die erzeugten dx-Object-Counts. Auch das Auszählen von Objekten mittels counter im im Konstruktor und Destruktor ergibt bei den überprüften Klassen das alles wieder freigegeben wird.
Ich benutze VS 2010. Das Programm macht intensiven Gebrauch von Multithreading. Bis auf den Taskmanager der verlorenen Speicher anzeigt, zeigen alle Tests in VS an das alles freigegeben wurde.

Hat jemand eine Idee wie ich dem Problem auf die Spur kommen könnte ?

Woran machst Du denn fest, dass Du Speicherlecks hast, wenn die diversen Detektoren keine anzeigen?

Laut Taskmanager ist nach dem Laden und dem Löschen des Projektes Speicher verloren gegangen. Theoretisch hätte ich doch den selben Speicherstand haben müssen oder ?

Nein. Die CRT und Windows haben jeweils Caches und komplexe Strategien zur Beschleunigung von kleinen Allokationen. Es ist völlig normal, wenn die Zahl im TaskManager in größeren Sprüngen steigt, als Du konkret allokierst, und nur verzögert oder gar nicht wieder sinkt, wenn Du freigibst.

Danke für deine schnelle Antwort. Wenn ich aber die Szene zum 2.Mal lade und wieder freigebe zeigt der Taskmanager wieder mehr als nach dem 1.Laden und freigeben an. Deshalb denke ich das wirklich Speicher verloren geht.

Wenn Du meinst.

gdsWizard hat geschrieben:Danke für deine schnelle Antwort. Wenn ich aber die Szene zum 2.Mal lade und wieder freigebe zeigt der Taskmanager wieder mehr als nach dem 1.Laden und freigeben an. Deshalb denke ich das wirklich Speicher verloren geht.

Du könntest es testweise statt 2 mal einfach 2 Millionen mal machen. Oder zumindest so oft, dass wenn der Speicher wirklich nie freigegeben würde, der Hauptspeicher mehrfach voll sein müsste.
Denn ganz ehrlich: Es nützt niemanden etwas, wenn von deinen zig Gigabyte Hauptspeicher der meiste die meiste Zeit leer ist, deshalb muss man sich auch nicht groß wundern, wenn da nicht aufgeräumt wird. Aber wenn du dein System an die Grenzen treibst und zwingst, Speicher freizugeben, um neuen allozieren zu können, wirst du merken ob du wirklich Speicherlecks hast oder nicht.

Ansonsten habe ich ganz gute Erfahrungen mit Dr. Memory gemacht. Damit habe ich einmal einen sehr sehr fiesen Bug gefunden und mag es seit dem wirklich gerne :D

Danke Jonathan, das werde ich ausprobieren. Leider muß ich jetzt erst mal kurz weg. Danach werde ich das "etliche" male laden probieren. Auch Dr.Memory sehe ich mir an. Mir ist aufgefallen das ein mit new char[100] und einem delete ohne [] die Inspektoren auch nix melden. Leider habe ich das auch schon ausgeschlossen.

Der Task-Manager hat auch verschiedene Spalten. Was da üblicherweise angezeigt wird, ist die Größe des Working Sets (also nur der Speicher, der aktiv benutzt wird). Klar, denn was anderes hat auch nicht wirklich Bedeutung für die Systemleistung.

„Commit Size“ ist deutlicher (ungefähr der allokierte Speicher), aber man muss bedenken dass Speicher dort nicht auftaucht bevor er zum ersten Mal beschrieben wird. (Selbst Kacheln, die mit Commit-Befehl allokiert werden, werden von Windows erst beim ersten Schreiben committet.)

Wahrscheinlich ist es also so, dass beim 2. Laden andere Kacheln allokiert werden und sie zusammen mit den Kacheln des ersten Ladens (denn der Heap Manager gibt, wie Schrompf erwähnte, nicht sofort wieder frei) als Arbeitssatz gezählt wurden, denn du hast sie in letzter Zeit verwendet.

Wenn du den Speicher messen willst: GetProcessHeaps(), HeapLock(), HeapWalk(). Das ignoriert zwar VirtualAlloc(), aber das ist auch der Sinn, denn du willst die Unkosten des Heap-Managers ignorieren. Und so ähnlich machen die Speicher-Tools das auch.

tl;dr: Bitte kein Speicher-Debugging mit dem Task-Manager.

@Jonathan
Leider crasht Dr.Memory bei mir bei Beenden des Programms. Auch muß ich die alte 32 Bit Version meines Programms nutzen. Da ist noch mein altes Framework. Ich habe mal mein Programm eine Szene 100 mal laden lassen und der Speicher wurde immer mehr belastet.

@Krishty
Natürlich auch für deinen hilfreichen Post Danke. Ich werde den Speicher also mit den Heap Funktionen untersuchen. Da ich aber noch nie direkt was mit den Heap Funktionen gemacht habe muß ich mir das aber erst genauer ansehen.

Hier mal eine Ausführung, was das alles so heißt im Task-Manager: http://windows.microsoft.com/de-de/wind ... =windows-7

Und ich möchte ebenfalls betonen: der TaskManager ist zum Tracken von leaks ungeeignet. Es gibt verschiedene Tools, die angeblich im Taskmanager Memory "freiräumen" in dem sie Windows voraukeln, kurzzeitig viel Speicher zu belegen. Und schwups: viel Memory ist nun plötzlich da. Als Aussage taugt das aber gar nicht. Immer im Hinterkopf behalten: benutze stets das Tool, das auch für diesen Zweck gemacht ist. Der Taskmanager ist keine Memory-Leak-Detektor!

Du solltest das Memory-Tracken auch mittels gflags und co anschalten und schauen, ob du wirklich ein problem hast. Wenn die sagen nein: glaube Ihnen.

Gruß Kimmi

Danke für den Tipp mit gflags. Das schaue ich mir an. Aber ich kann mir nur schwer vorstellen das ein Programm das nach dem Laden einer Szene nur ein paar 100 MByte belegt nach x mal freigeben und neu laden 7 Gbyte belegt. Hätte ich die Schleife nicht abgebrochen dann hätte er noch angefangen auszulagern. Für mich kann da was nicht stimmen. Ich untersuche das weiter.

Du kannst mal schauen, ob sich irgendwelche Arrays mit Werten füllen, du also beim Befreien der Szene irgendwelche Sachen nicht wirklich freigibst. Zu jeder Allokation musst du genau sagen können, an welcher Stelle der Speicher wieder freigegeben wird, dann ist dein Programm Leak-Frei.

Ich vermute auch ( wie antisteo ) das es etwas ist das ich am Ende doch freigebe. Ich bin dabei das Problem einzukreisen. Möglicherweis tritt das Problem beim Multithreaded - Teil auf. Denn wenn ich das weglasse tritt das Phänomen scheinbar nicht auf. Es tritt scheinbar auch nicht bei jedem Berechnen auf. Das ist ein weiterer Hinweis auf das Multithreading.

Ich habe den Bug gefunden. Meine MessagePort class hat vergessen zurückgeschickte Messages zu löschen, so haben sich diese im Port gesammelt. Wird der Port zerstört löscht er auch alle Nachrichten darin. Deshalb hat VS keine Leaks angezeigt. Es gab einfach keine. Diese Klassen sind uralt. Ich hatte aber vor ein paar Monaten was geändert und diesen Bug produziert. Wenn man so lange sucht ist es meist ein sinnloser Fehler wie dieser. Aber so habe ich Dr.Memory kennengelernt. Mit ihm habe ich einen Bug im Umgang mit dem GDI gefunden, der sich aber nie bemerkbar gemacht hatte.