Speicherlecks in fremdem Code/Programm finden

[Zacherl]

Bei neueren VS Versionen könnte evtl. das hier helfen:
https://msdn.microsoft.com/en-us/lib...v=vs.140).aspx

Visual Studio 2015 Community Edition gibt es als kostenlosen Download und die Express Variante kann man auch als Testversion beziehen.

-

Der Leak in CIniFile ist glaube ich schonmal ein False-Positive. Die Container sind alle Stack-allocated; sprich: sie werden automatisch freigegeben, sobald die Klasseninstanz aus dem Scope läuft. Generell ist es in C++ eigentlich sehr schwierig Speicher zu leaken. Ausschau halten solltest du nach allen Stellen, die entweder Objekte mit new auf dem Heap erstellen oder manuellen malloc , VirtualAlloc , etc. Aufrufen.

[Dalai]

Zitat von Zacherl:

Bei neueren VS Versionen könnte evtl. das hier helfen:
https://msdn.microsoft.com/en-us/lib...v=vs.140).aspx

Funktioniert zwar auch in VS 2008 Express, gibt aber weniger und deutlich kryptischere Ausgaben, mit denen ich noch weniger anfangen kann als mit dem Leak Report vom VLD.

Zitat:

Generell ist es in C++ eigentlich sehr schwierig Speicher zu leaken.

Schwieriger als in Delphi? Kann ich mir kaum vorstellen. Bei beiden kann man Objekte erzeugen und vergessen, sie wieder wegzuräumen. Wenn das in Intervallen und/oder Schleifen passiert, vervielfacht sich das kleine Leck - und genau in die Richtung geht meine Vermutung.

Zitat:

Ausschau halten solltest du nach allen Stellen, die entweder Objekte mit new auf dem Heap erstellen oder manuellen malloc , VirtualAlloc , etc. Aufrufen.

Ja, das habe ich bereits getan. VirtualAlloc findet sich im Code überhaupt nicht. malloc und new sind ein paar Mal enthalten, aber ich bin mir unsicher, ob es zu jedem einen entsprechenden Aufräumaufruf (free und delete) gibt, weil die teilweise an völlig unterschiedlichen Stellen zu finden sind. Die (Un)art, Code auch im Header zu haben, macht es nicht einfacher.

---

Der gesamte Report von VLD ist übrigens noch deutlich länger (über 100 KB) und enthält am Ende diese Zeilen:

Code:

Visual Leak Detector detected 43 memory leaks (9432 bytes).
Largest number used: 11008 bytes.
Total allocations: 46696 bytes.
Visual Leak Detector is now exiting.

Ich kann den bei Interesse gern zur Verfügung stellen.

Grüße
Dalai

[Mikkey]

Zitat von Dalai:

Schwieriger als in Delphi? Kann ich mir kaum vorstellen. Bei beiden kann man Objekte erzeugen und vergessen, sie wieder wegzuräumen. Wenn das in Intervallen und/oder Schleifen passiert, vervielfacht sich das kleine Leck - und genau in die Richtung geht meine Vermutung.

In der Tat! Heutzutage verwendet man eigentlich in C++ kein new oder malloc mehr. Die STL bietet einen unfangreichen Satz an Smart-Pointern, so dass man darauf nicht mehr angewiesen ist. Ausnahmen sind die Verwendung anderer Laufzeitumgebungen, die das Erstellen von Objekten mit new voraussetzen.

Anderes Beispiel:

Delphi: dlg := new TMyDialog(..) --> dlg.Free();
C++: MyDialog dlg(..);

Stack-alloziierte Objekte gibt es in Delphi nicht, deshalb muss man sie auch wegräumen.

[nahpets]

Hab' mir mal die INI zum Programm angeschaut. In diesem Abschnitt

Code:

[Plugins]
; Plugin Section, 1 enables plugin, 0 disables
Disk=1
Memory=1
Processes=1
Network=1
MbmTemp=1
MbmVoltage=1
MbmFan=1
MbmMhz=1
SMART=0
HD=1
Cpu=1
SpeedFan=1
External=1

kann man doch konfigurieren, welche Plugins genutzt werden sollen.

Wenn möglich, einen eigenen Server zum Testen nehmen und erstmal alle Plugins deaktivieren.

Speicherentwicklung über ein paar Stunden beobachten. Wenn da nix passiert, der Reihe nach jeweils ein Plugin aktivieren und wieder beobachten.

Leider wird das sehr zeitaufwändig, wenn man 'ne Woche beobachten muss, um Speicherfresser zu entdecken. Eventuell kannst Du aber auch in einem kürzeren Zeitraum schon eine Tendenz erkennen. Gehe mal davon aus, dass der Speicherverbrauch kontinuierlich ansteigt und nicht ab und an sprunghaft.

Da der Service auch auf die Windows-API zugreift, muss das Speicherloch nicht zwingend in dem Dienst sein, sondern kann auch irgendwo in der API liegen. Oder die Speicherlecks könnten eventuell auch durch fehlerhafte Nutzung der API hervorgerufen werden.
Will meinen: Es muss nicht zwingend an eigener Speicherreservierung und fehlender Speicherfreigabe liegen.

[Dalai]

Zitat von nahpets:

Wenn möglich, einen eigenen Server zum Testen nehmen und erstmal alle Plugins deaktivieren.

Ja, die Idee hatte ich gestern auch noch. Über den Weg könnte ich jedenfalls rausfinden, in welchem/n Plugin/s Lecks stecken. Alle deaktivieren geht aber nicht, es muss mindestens eines aktiviert sein, sonst gibt's keine Werte .

Zitat:

Eventuell kannst Du aber auch in einem kürzeren Zeitraum schon eine Tendenz erkennen.

Kann man. Es sind zwar innerhalb weniger Stunden nur ein paar KB Mehrverbrauch, vielleicht auch 1 MB, aber schon diese geringe Zunahme sollte nicht sein.

Zitat:

Gehe mal davon aus, dass der Speicherverbrauch kontinuierlich ansteigt und nicht ab und an sprunghaft.

Zum Abfragezeitpunkt steigt der Bedarf kurzzeitig an, geht dann aber wieder zurück auf den Ursprungswert - plus ein paar Byte/KB. Über einen längeren Zeitraum gesehen steigt der Speicherverbrauch kontinuierlich an, richtig.

Zitat:

Da der Service auch auf die Windows-API zugreift, muss das Speicherloch nicht zwingend in dem Dienst sein, sondern kann auch irgendwo in der API liegen.

Auf allen genutzten Systemen, von XP bis nach Win7, bei x86 und x64? Unwahrscheinlich. Lustigerweise gibt's keine Lecks auf Win2k, wobei ich hier nicht ausschließen kann, dass die unterschiedlichen Codepfade dafür verantwortlich sind.

Zitat:

Oder die Speicherlecks könnten eventuell auch durch fehlerhafte Nutzung der API hervorgerufen werden.

He, wie finde ich das raus? Jede einzelne Funktion angucken? Eieiei.


Ich werd erstmal den Node mit nur je einem Plugin gleichzeitg laufen lassen und über einige Stunden beobachten. Das dauert zwar länger, kann aber nebenbei laufen.

Grüße
Dalai

[nahpets]

Denke, dass es das Sinnvollste ist, erstmal pro Plugin zu testen. Wenn dann erkennbar ist, dass nur eines (und hoffentlich nicht mehrere) ein Problem verursacht.

Dann kann man anfangen die Quellen durchzusehen, um genauer zu erfahren, wo da was klemmen könnte.

Probleme mit Speicherlöschern und dem Zugriff über WMI hatte ich eigentlich bei allen Windowsversionen. Generell würd' ich eine "kontinuierliche" oder aber auch "versionsübergreifende" Fehlermöglichkeit nicht zwingend ausschließen.

Deine Bemerkung, dass der Fehler unter W2K nicht auftritt, ist (finde ich) wesentlich. W2K ist wohl die älteste Windowsversion, die Du in Betrieb hast.
Daraus schließ ich jetzt erstmal ganz naiv, dass bei der ersten Version von Windows, die nach W2K heraus kam, irgendeine Änderung gemacht wurde, die in den Quellen nicht "nachgezogen" wurde.
Oder der Fehler tritt bei der Nutzung einer Funktion auf, die es unter W2K noch nicht gab.

[Dalai]

Zitat von nahpets:

Daraus schließ ich jetzt erstmal ganz naiv, dass bei der ersten Version von Windows, die nach W2K heraus kam, irgendeine Änderung gemacht wurde, die in den Quellen nicht "nachgezogen" wurde.

Mmh, vielleicht hätte ich das weiter ausführen sollen. Die unterschiedlichen Codepfade für verschiedene Windows-Versionen gibt es in der offiziellen Version nicht (weder in 1.5 noch 1.6). Dafür funktionieren aber bestimmte Dinge unter Win2k gar nicht; soweit ich das momentan nachvollziehen kann, hatte das irgendwas mit dem Performance Counter Plugin zu tun.

Deshalb hatte ich vor vielen Jahren eine kleine Änderung eingebaut, die in den Kommentaren auf der alten Homepages des Autors zu finden war, um den Fehler zu beseitigen. Die Änderung bewirkt, dass die Fehlerprüfung in zwei Funktionen (PerfCounterMuninNodePlugin::OpenCounter() und PerfCounterMuninNodePlugin::GetConfig()) anders erfolgt. Wie gesagt ist das nur eine kleine Änderung an einem der Plugins, der restliche Code inkl. aller anderen Plugins blieb davon unberührt.

Zitat:

Oder der Fehler tritt bei der Nutzung einer Funktion auf, die es unter W2K noch nicht gab.

Ja, in die Richtung ging meine Vermutung auch, aber ich bin nicht in der Lage, die Unterschiede zu analysieren, um den Fehler zu finden. Das Performance Counter Plugin hatte ich schon einmal ausgeschaltet, aber Lecks gab's trotzdem.


Warten wir mal ab, was die Untersuchung der einzelnen Plugins bringt. Ärgert mich, dass ich diese Idee nicht früher hatte; aber vielleicht hatte ich sie schon, weiß aber das Testergebnis nicht mehr, schließlich schlage ich mich mit dem Problem schon seit Jahren rum...

Grüße
Dalai

[Rollo62]

Zitat von Zacherl:

Generell ist es in C++ eigentlich sehr schwierig Speicher zu leaken.

Womöglich meinst du wenn man konsequent alle Objekte per SmartPointer/AutoPointer/UniquePointer anlegt ?
Normale Objekte verhalten sich so ähnlich wie Delphi-Objekte auch.

Rolf

[Zacherl]

Zitat von Rollo62:

Zitat von Zacherl:

Generell ist es in C++ eigentlich sehr schwierig Speicher zu leaken.

Womöglich meinst du wenn man konsequent alle Objekte per SmartPointer/AutoPointer/UniquePointer anlegt ?
Normale Objekte verhalten sich so ähnlich wie Delphi-Objekte auch.

Das war eigentlich mehr auf die Tatsache bezogen, dass die Objekte standardmäßig Stack-allocated sind und automatisch freigegeben werden, sobald sie aus dem Scope laufen. Heap-Allocation per new sollte nach Möglichkeit immer vermieden werden, wenn man C++ Code schreibt (gibt natürlich Ausnahmen).