Speicherlecks in fremdem Code/Programm finden

[nahpets]

Um hier konkret mit Ideen aushelfen zu können, sind die Angaben zum Service etwas zu knapp.

Was macht er? (Grobe Beschreibung der Aufgabe.)

Hatte vor Jahren mal mit 'nem in Delphi geschriebenen Service so ein Speicherproblem.

Grob: Der Service sollte aus der Serverlandschaft alle 15 Minuten Statusinformationen sammeln und daraus Webseiten generieren, die per Webserver abrufbar waren.

Für das Sammeln der Statusinformationen wurde unter Anderem per WMI auf die Server zugegriffen. Und darin war irgendwo ein Speicherloch, das wir nicht wegbekommen haben. Haben dann aus dem Service ein Konsolenprogramm gemacht, das per Taskplaner alle 15 Minuten gestartet wurde.

Damit war das Speicherproblem zwar nicht behoben, aber fiel nicht mehr auf, da es nur noch für die Laufzeit des Konsolenprogrammes bestand.

[Dalai]

Zitat von nahpets:

Um hier konkret mit Ideen aushelfen zu können, sind die Angaben zum Service etwas zu knapp.

Was macht er? (Grobe Beschreibung der Aufgabe.)

Der Dienst wird per Netzwerk von einem Sammler (dem "Server") alle 5 Minuten kontaktiert. Der Dienst ermittelt Angaben zum Systemstatus, darunter Auslastung von CPU und Speicher, sowie Netzwerktraffic, Dateisystembelegung, ggf. Systemtemperaturen usw. und liefert sie an den Server. Der Server verarbeitet diese Informationen und erzeugt daraus Graphen. Die Sache geht also in die gleiche Richtung wie dein Service.

Zitat von jaenicke:

Kannst du da vielleicht Beispiele posten?

Klar, kein Problem.

Code:

Visual Leak Detector Version 2.3 installed.
    Outputting the report to the debugger and to c:\VC\munin-node\memory_leak_report.txt
WARNING: Visual Leak Detector detected memory leaks!
---------- Block 116 at 0x003D5C00: 64 bytes ----------
  Call Stack:
    c:\programme\microsoft visual studio 9.0\vc\include\xmemory (43): munin-node.exe!std::_Allocate<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > + 0xC bytes
    c:\programme\microsoft visual studio 9.0\vc\include\xmemory (145): munin-node.exe!std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >::allocate + 0xB bytes
    c:\programme\microsoft visual studio 9.0\vc\include\vector (1178): munin-node.exe!std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::_Insert_n + 0xF bytes
    c:\programme\microsoft visual studio 9.0\vc\include\vector (719): munin-node.exe!std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::resize + 0x5C bytes
    c:\vc\munin-node\src\extra\inifile.cpp (227): munin-node.exe!CIniFile::SetValue
    c:\vc\munin-node\src\extra\inifile.cpp (87): munin-node.exe!CIniFile::ReadFile
    c:\vc\munin-node\src\core\munin-node.cpp (65): munin-node.exe!main
    f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (582): munin-node.exe!__tmainCRTStartup + 0x19 bytes
    f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (399): munin-node.exe!mainCRTStartup
    0x7C817067 (File and line number not available): kernel32.dll!RegisterWaitForInputIdle + 0x49 bytes
  Data:
    00 00 00 00    CD CD CD CD    42 72 6F 61    64 63 61 73     ........ Broadcas
    74 49 50 00    CD CD CD CD    0B 00 00 00    0F 00 00 00     tIP..... ........
    00 00 00 00    CD CD CD CD    55 49 44 00    CD CD CD CD     ........ UID.....
    CD CD CD CD    CD CD CD CD    03 00 00 00    0F 00 00 00     ........ ........


---------- Block 127 at 0x003D5C80: 4 bytes ----------
  Call Stack:
    c:\vc\munin-node\src\core\muninpluginmanager.cpp (61): munin-node.exe!MuninPluginManager::MuninPluginManager + 0x7 bytes
    0x004665C5 (File and line number not available): munin-node.exe!MuninNodeServer::MuninNodeServer + 0x65 bytes
    c:\vc\munin-node\src\core\service.cpp (135): munin-node.exe!CService::Run + 0x2E bytes
    c:\vc\munin-node\src\core\service.cpp (63): munin-node.exe!CService::Start
    c:\vc\munin-node\src\core\munin-node.cpp (110): munin-node.exe!main
    f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (582): munin-node.exe!__tmainCRTStartup + 0x19 bytes
    f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (399): munin-node.exe!mainCRTStartup
    0x7C817067 (File and line number not available): kernel32.dll!RegisterWaitForInputIdle + 0x49 bytes
  Data:
    E0 7F 47 00                                                  ..G..... ........


---------- Block 1 at 0x003D5FD8: 24 bytes ----------
  Call Stack:
    c:\programme\microsoft visual studio 9.0\vc\include\xmemory (43): munin-node.exe!std::_Allocate<std::_Tree_nod<std::_Tmap_traits<unsigned long,void *,std::less<unsigned long>,std::allocator<std::pair<unsigned long const ,void *> >,0> >::_Node> + 0xC bytes
    c:\programme\microsoft visual studio 9.0\vc\include\xmemory (145): munin-node.exe!std::allocator<std::_Tree_nod<std::_Tmap_traits<unsigned long,void *,std::less<unsigned long>,std::allocator<std::pair<unsigned long const ,void *> >,0> >::_Node>::allocate + 0xB bytes
    c:\programme\microsoft visual studio 9.0\vc\include\xtree (1384): munin-node.exe!std::_Tree<std::_Tmap_traits<unsigned long,void *,std::less<unsigned long>,std::allocator<std::pair<unsigned long const ,void *> >,0> >::_Buynode + 0xD bytes
    c:\programme\microsoft visual studio 9.0\vc\include\xtree (1178): munin-node.exe!std::_Tree<std::_Tmap_traits<unsigned long,void *,std::less<unsigned long>,std::allocator<std::pair<unsigned long const ,void *> >,0> >::_Init + 0x8 bytes
    c:\programme\microsoft visual studio 9.0\vc\include\xtree (511): munin-node.exe!std::_Tree<std::_Tmap_traits<unsigned long,void *,std::less<unsigned long>,std::allocator<std::pair<unsigned long const ,void *> >,0> >::_Tree<std::_Tmap_traits<unsigned long,void *,std::less<unsigned long>,std::allocator<std::pair<unsigned long const ,vo
    c:\programme\microsoft visual studio 9.0\vc\include\map (104): munin-node.exe!std::map<unsigned long,void *,std::less<unsigned long>,std::allocator<std::pair<unsigned long const ,void *> > >::map<unsigned long,void *,std::less<unsigned long>,std::allocator<std::pair<unsigned long const ,void *> > >
    c:\vc\munin-node\src\plugins\disk\smartreader.cpp (14): munin-node.exe!CSmartReader::CSmartReader + 0x59 bytes
    c:\vc\munin-node\src\plugins\disk\smartreader.cpp (393): munin-node.exe!CSmartReader2::CSmartReader2 + 0x2B bytes
    c:\vc\munin-node\src\plugins\disk\smartreader.cpp (413): munin-node.exe!`dynamic initializer for 'g_SmartReader'' + 0x28 bytes
    0x1023C02C (File and line number not available): MSVCR90D.dll!initterm + 0x1C bytes
    f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (497): munin-node.exe!__tmainCRTStartup + 0xF bytes
    f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (399): munin-node.exe!mainCRTStartup
    0x7C817067 (File and line number not available): kernel32.dll!RegisterWaitForInputIdle + 0x49 bytes
  Data:
    D8 5F 3D 00    D8 5F 3D 00    D8 5F 3D 00    CD CD CD CD     ._=.._=. ._=.....
    CD CD CD CD    01 01 CD CD                                   ........ ........


---------- Block 2 at 0x003D6030: 548 bytes ----------
  Call Stack:
    c:\programme\microsoft visual studio 9.0\vc\include\xmemory (43): munin-node.exe!std::_Allocate<std::_Tree_nod<std::_Tmap_traits<unsigned char,ST_SMART_DETAILS,std::less<unsigned char>,std::allocator<std::pair<unsigned char const ,ST_SMART_DETAILS> >,0> >::_Node> + 0xF bytes
    c:\programme\microsoft visual studio 9.0\vc\include\xmemory (145): munin-node.exe!std::allocator<std::_Tree_nod<std::_Tmap_traits<unsigned char,ST_SMART_DETAILS,std::less<unsigned char>,std::allocator<std::pair<unsigned char const ,ST_SMART_DETAILS> >,0> >::_Node>::allocate + 0xB bytes
    c:\programme\microsoft visual studio 9.0\vc\include\xtree (1384): munin-node.exe!std::_Tree<std::_Tmap_traits<unsigned char,ST_SMART_DETAILS,std::less<unsigned char>,std::allocator<std::pair<unsigned char const ,ST_SMART_DETAILS> >,0> >::_Buynode + 0xD bytes
    c:\programme\microsoft visual studio 9.0\vc\include\xtree (1178): munin-node.exe!std::_Tree<std::_Tmap_traits<unsigned char,ST_SMART_DETAILS,std::less<unsigned char>,std::allocator<std::pair<unsigned char const ,ST_SMART_DETAILS> >,0> >::_Init + 0x8 bytes
    c:\programme\microsoft visual studio 9.0\vc\include\xtree (511): munin-node.exe!std::_Tree<std::_Tmap_traits<unsigned char,ST_SMART_DETAILS,std::less<unsigned char>,std::allocator<std::pair<unsigned char const ,ST_SMART_DETAILS> >,0> >::_Tree<std::_Tmap_traits<unsigned char,ST_SMART_DETAILS,std::less<unsigned char>,std::allocator<std
    c:\programme\microsoft visual studio 9.0\vc\include\map (104): munin-node.exe!std::map<unsigned char,ST_SMART_DETAILS,std::less<unsigned char>,std::allocator<std::pair<unsigned char const ,ST_SMART_DETAILS> > >::map<unsigned char,ST_SMART_DETAILS,std::less<unsigned char>,std::allocator<std::pair<unsigned char const ,ST_SMART_DETAIL
    c:\vc\munin-node\src\plugins\disk\smartreader.cpp (14): munin-node.exe!CSmartReader::CSmartReader + 0x6E bytes
    c:\vc\munin-node\src\plugins\disk\smartreader.cpp (393): munin-node.exe!CSmartReader2::CSmartReader2 + 0x2B bytes
    c:\vc\munin-node\src\plugins\disk\smartreader.cpp (413): munin-node.exe!`dynamic initializer for 'g_SmartReader'' + 0x28 bytes
    0x1023C02C (File and line number not available): MSVCR90D.dll!initterm + 0x1C bytes
    f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (497): munin-node.exe!__tmainCRTStartup + 0xF bytes
    f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (399): munin-node.exe!mainCRTStartup
    0x7C817067 (File and line number not available): kernel32.dll!RegisterWaitForInputIdle + 0x49 bytes
  Data:
    30 60 3D 00    30 60 3D 00    30 60 3D 00    CD CD CD CD     0`=.0`=. 0`=.....
    CD CD CD CD    CD CD CD CD    CD CD CD CD    CD CD CD CD     ........ ........
    CD CD CD CD    CD CD CD CD    CD CD CD CD    CD CD CD CD     ........ ........
    CD CD CD CD    CD CD CD CD    CD CD CD CD    CD CD CD CD     ........ ........
    CD CD CD CD    CD CD CD CD    CD CD CD CD    CD CD CD CD     ........ ........
    CD CD CD CD    CD CD CD CD    CD CD CD CD    CD CD CD CD     ........ ........
    CD CD CD CD    CD CD CD CD    CD CD CD CD    CD CD CD CD     ........ ........
    CD CD CD CD    CD CD CD CD    CD CD CD CD    CD CD CD CD     ........ ........
    CD CD CD CD    CD CD CD CD    CD CD CD CD    CD CD CD CD     ........ ........
    CD CD CD CD    CD CD CD CD    CD CD CD CD    CD CD CD CD     ........ ........
    CD CD CD CD    CD CD CD CD    CD CD CD CD    CD CD CD CD     ........ ........
    CD CD CD CD    CD CD CD CD    CD CD CD CD    CD CD CD CD     ........ ........
    CD CD CD CD    CD CD CD CD    CD CD CD CD    CD CD CD CD     ........ ........
    CD CD CD CD    CD CD CD CD    CD CD CD CD    CD CD CD CD     ........ ........
    CD CD CD CD    CD CD CD CD    CD CD CD CD    CD CD CD CD     ........ ........
    CD CD CD CD    CD CD CD CD    CD CD CD CD    CD CD CD CD     ........ ........

Aus dem Call Stack wird auch klar, dass es um Munin geht, konkret Munin Node for Windows (aktuell bei Github). Im Laufe der vergangenen Jahre habe ich immer mal wieder Bugs behoben und einige Funktionen ergänzt, aber die Speicherlecks gibt's auch mit der ursprünglichen unveränderten Version 1.5.1942.

Grüße
Dalai

[Dalai]

Eine Warnung für diejenigen, die sich den Dienst installieren möchten: Auf gar keinen Fall munin-node.exe mit dem Parameter -uninstall aufrufen, sonst wird die komplette Ereignisanzeige (Bereich Anwendungen) zerstört! Das ist der gravierendste Bug, den ich behoben habe; in der aktuellen Beta (1.6.1.0) von Github scheint er ebenfalls behoben zu sein.

Grüße
Dalai

[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.

[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).