Speicherlecks in fremdem Code/Programm finden

[nahpets]

Meine C++-Kenntnisse tendieren gegen 0.

In der von Dir genannten Routine wird in 'ner Schleife mehr oder weniger häufig

Code:

currentBlock = new xAPBlockHeader(currentPos);

bzw.

Code:

currentBlock = new xAPBlockData(currentPos);

aufgerufen. Hier wird ja wohl irgendwas neu erstellt. Was ich nicht finden kann ist die Stelle, an der wieder aufgeräumt wird.

[Zacherl]

Aufgräumt wird später in Zeile 271, aber so wie ich das sehe wird im Block von 239 - 249 unter bestimmten Konditionen das push_back vergessen.

[Dalai]

Zitat von Zacherl:

Aufgräumt wird später in Zeile 271 [...]

So ist es.

Zitat:

[...] aber so wie ich das sehe wird im Block von 239 - 249 unter bestimmten Konditionen das push_back vergessen.

Nein. Man muss hier leider ein bisschen um die Ecke denken. Der Header wird erst beim folgenden Schleifendurchlauf in die Variable blocks aufgenommen. Der letzte Datenblock folgt dann durch das push_back() nach der while-Schleife.

---

Ich glaube aber, das Leck gefunden zu haben - ich hoffe, ich bin da nicht vorschnell (Test läuft gerade). Im xAP-Protokoll, das SpeedFan da benutzt, wird Broadcasting eingesetzt, d.h. die Pakete aller Rechner kommen auf jedem Munin-Node an. Zusätzlich gibt es wohl Heartbeat-Pakete (Beispiel in example2.txt), die anzeigen "ich lebe noch".

Der Inhalt der Variable blocks wird durch die while-Schleife zusammengebaut, egal, was da für ein Paket reinkommt. Für jeden Abschnitt des Pakets wird mit new ein currentBlock erzeugt, und einzeln an blocks angehängt. In Zeile 267 wird der Inhalt der Variable blocks nur dann an die Klassenvariable m_Blocks weitergegeben, wenn die UID übereinstimmt (und es ein Datenpaket war und kein Heartbeat).

Aber was passiert mit dem Inhalt der Variable blocks, wenn das nicht zutrifft, es also das Paket mit einer anderen UID oder ein Heartbeat war? Der dengelt weiter im Speicher rum, ohne zerstört zu werden, denn die Zerstörung passiert nur mit dem Inhalt der Klassenvariable beim nächsten Paket. Das erklärt auch, warum die Zunahme des Speichers mit der Anzahl der mit SpeedFan (mit aktiviertem xAP) laufenden Rechner im LAN ansteigt - mehr Heartbeats, mehr auf dem Heap erzeugte Objekte, die nicht wieder weggeräumt werden.

Meine Lösung sieht daher momentan so aus, dass ich in Zeile 276 folgenden Teil zur if-Bedingung aus 267 ergänzt habe:

Code:

} else {
    for (std::vector<xAPBlock *>::iterator it = blocks.begin(); it != blocks.end(); it++)
      delete *it;
}

um alle Objekte in blocks wieder aufzuräumen. Das sollte alle nötigen Fälle abdecken.

Ob's das wirklich ist (und das einzige Leck), wird sich zeigen.

Grüße
Dalai

[Delphi-Laie]

Trägt zwar nichts zur Problemlösung bei, soll aber verdeutlichen, daß es den Menschen wie den Leuten geht: Wen zur Abwechslung mal interessiert, wie ein sehr schwierig aufzuspürender Softwarefehler wochenlang gesucht, irgendwann gefunden und dann recht einfach beseitigt wurde, der möge diese Dokumentation dazu lesen.

[Dalai]

Kleiner Nachtrag: Das Speicherleck ist definitiv gestopft. Nach 7,5 Stunden Laufzeit und einer Zunahme des Working Set von nur ca. 40 KB kann ich das guten Gewissens behaupten; diesmal lief es auf einem Win7 x64 mit x64 Prozess, daher ist der Wert nur bedingt vergleichbar mit den vorherigen. Möglicherweise sind noch weitere kleinere Lecks enthalten, aber das kann nur mit einem wesentlich längeren Untersuchungszeitraum ermittelt werden.

Ich habe den Code noch etwas angepasst:

Code:

size_t SpeedFanNodePlugin::ListenerThread::ProcessBuffer(char *buffer)
{
  ...
  bool clearblocks = false;
  ...

  if (headerBlock != NULL) {
    ...
    if (headerBlock->uid == uid && headerBlock->xAPClass == "PC.status") {
    ...
    } else {
      clearblocks = true;
    }
  } else {
    clearblocks = true;
  }

  if (clearblocks)
    for (std::vector<xAPBlock *>::iterator it = blocks.begin(); it != blocks.end(); it++)
      delete *it;
  ...
}

So wird in jedem Fall aufgeräumt, wenn's nix zu verarbeiten gab. Wahrscheinlich könnte man die boolsche Variable sogar weglassen, weil die Funktion im "guten" Fall sowieso vorher mit return verlassen wird.

Danke an alle Beteiligten!

Grüße
Dalai

[Dalai]

Nach gut zwei Wochen ununterbrochener Laufzeit des Munin Node auf meinem Server (XP) und einer einzigen Zunahme des Working Set um ~75 KiB nach einem Tag (aber keiner weiteren) kann ich behaupten, dass das Leck wohl das einzige war. Beschränkt wird diese Behauptung lediglich durch das OS sowie die von mir verwendete Konfiguration, in der nahezu alle Plugins eingeschaltet sind. Ich nehme aber schon an, dass sich der Node auf anderen Windows-Versionen analog verhält.

Klasse, endlich Munin Node auf Windows-Systemen ohne geplanten Task, der selbigen jede Woche neu startet .

Danke und Grüße
Dalai