Besser als visual leak detector

[marfi]

Hallo Leute,

gibt es eigentlich etwas besseres zur Lecksuche als VLD? Ich habe damit so meine Probeme. Mich nervt das delete in einer anderen Funktion als Leck angezeigt wird. Vielleicht gibt es ja eine Einstellungsmöglichkeit, ich habe aber unter den settings nicht gefunden.

So meldet VLD dabei memory leaks!

Code: Alles auswählen

class CTest
{
public:
	CTest(){m_pI = NULL;};
	~CTest(){};

	void start()
	{
		m_pI = new int;
	}

	void end()
	{
		if(m_pI)
			delete(m_pI);
	}
	
private:
	int* m_pI;
};

int main ()
{
	CTest te;

	te.start();

	te.end();

	return 0;
}

[Jonathan]

Ich habe mal Dr. Memory benutzt, weil Valgrind nur für Linux ist. Ist einiges an Aufwand, aber ich habe damit einen echt fiesen Fehler gefunden, den ich sonst nie im Leben aufgestöbert hätte.

[ponx]

Ich hatte auch viel Ärger mit Visual Leak Detector, manches findet er einfach nicht, und in einigen Projekten hab ich nicht zum Laufen gekriegt. Ich kann Dr. Memory auch sehr empfehlen.

[eXile]

Ich kann Dr. Memory auch sehr empfehlen.

Eine halbwegs vollständige Suppression-Datei hatte ich mal hier gepostet.

[marfi]

Dr Memory habe ich mal kurz überflogen. Es hatte den anschein, als wäre es etwas umständlich.

Vielleicht täuscht auch der erste Eindruck :)

Ich werde mir Dr. Memory noch mal ansehen.

Vielen Dank für den Tip

[Jonathan]

Ja, ich musste etwas arbeiten, bis ich alles so kompiliert hatte, das Dr. Mem es benutzen mag (man darf die Debug Runtime nicht benutzen). Aber die Mühe war es wert, den Fehler hätte ich sonst nicht gefunden.

[Sternmull]

Das ersetzen von Speicherverwaltungsfunktionen während des Builds ist meiner Meinung nach keine brauchbare Lösung. Statt dessen verwende ich UMDH. Das hat mir in den letzten Jahren gute Dienste geleistet. Kostet aber ein paar Minuten Einarbeitungszeit und hat keine bunte Benutzeroberfläche oder so. Es aber äußerst Zweckdienlich. Das Tool ist teil der "Debugging Tools For Windows", ist auch z.B. hier beschrieben, die kostenlos heruntergeladen und genutzt werden können.

[eXile]

Das ersetzen von Speicherverwaltungsfunktionen während des Builds ist meiner Meinung nach keine brauchbare Lösung. Statt dessen verwende ich UMDH. Das hat mir in den letzten Jahren gute Dienste geleistet. Kostet aber ein paar Minuten Einarbeitungszeit und hat keine bunte Benutzeroberfläche oder so. Es aber äußerst Zweckdienlich. Das Tool ist teil der "Debugging Tools For Windows", ist auch z.B. hier beschrieben, die kostenlos heruntergeladen und genutzt werden können.

Ich habe tatsächlich alle Tools einmal durchprobiert; an Dr. Memory kommt kein anderes heran. Für andere, nicht-speicherbezogene Fehler empfehle ich den Application Verifier.

[Sternmull]

Mit UMDH läuft das so ab:

• Anwendung starten und in einen Zustand bringen ab dem man auf Leaks checken will (der Speicher der beim Start alloziert wird ist einem ja meistens egal, bzw. ein andere Thema).
• Aktuellen Zustand als A von UMDH speichern lassen.
• Aktionen ausführen die man auf Memory Leaks prüfen will.
• Anwendung in einen Zustand bringen bei dem sie eigentlich wieder allen Speicher freigegeben haben sollte der nach A angefordert wurde.
• Einen Zweiten Zustand B von UMDH aufnehmen lassen.

Danach kann man mit UMDH die aufgenommenen Zustände vergleichen. Das Ergebnis wäre hier z.B. eine Liste der Allokationen die in B vorhanden waren, aber nicht in A. Die Liste ist nach Größe sortiert und enthält die Stacktraces über die die Allokation stattgefunden hat.

Get so was mit Dr. Memory auch? Nach einem kurzen Blick in die Doku sieht es für mich so aus als würden dort grundsätzlich alle Allokationen aufgelistet werden. Wenn aber bei der Initialisierung des Programms mal ein paar Megabyte angefordert werden die dann bis zum Ende nicht freigegeben werden, dann ist das normalerweise unkritisch. Was kritisch ist sind bei langlebigen Programmen die Leaks die zu einem ständigen Zuwachs führen. Ich hatte da mal eins das wirklich nur wenige Bytes pro Minute geleaked hat. Nach ein paar Tagen kommt da natürlich eine auffallende Menge zusammen. Aber wenn man das debuggen will, möchte man nicht erst Tage warten. D.h. ich will dann nur wissen was zwischen einem Programmzustand A und einem Zustand B hinzugekommen ist. Das ganze Gerassel was davor passiert ist interessiert mich dann nicht (in dem würde mein kleines Leak sich ja nicht mehr auffallen).

Es geht mir nicht darum Werbung für UMDH zu machen. Mich würde nur interessieren ob Dr. Memory denn wirklich die Features hat die für mich unverzichtbar sind. Aus einer Aussage wie "an Dr. Memory kommt kein anderes heran" geht das nicht eindeutig hervor :)

[eXile]

Get so was mit Dr. Memory auch? Nach einem kurzen Blick in die Doku sieht es für mich so aus als würden dort grundsätzlich alle Allokationen aufgelistet werden.

Nicht direkt, aber indirekt; du kannst das folgendermaßen umgehen: Einfach die Leaks unterdrücken, die du nicht sehen willst. Das ist einmal am Anfang etwas Arbeit, die Callstacks in die Suppression-Datei zu kopieren; aber danach geht das ganz problemlos.

Wenn aber bei der Initialisierung des Programms mal ein paar Megabyte angefordert werden die dann bis zum Ende nicht freigegeben werden, dann ist das normalerweise unkritisch.

Unkritisch wohl ja; unschön wohl auch. Wenigstens wird es durch die Suppressions explizit gemacht. ;) Dazu auch: Welche Arten es von Leaks es eigentlich gibt:

1. Memory that is still reachable by the application. This is NOT considered a leak. It is reported as "still-reachable allocation(s)" in Dr. Memory's summary. Many applications do not explicitly free memory whose lifetime matches the process lifetime and this is not considered an error by Dr. Memory.
2. Memory that is definitely not reachable by the application (at least, not by an aligned pointer to the start or middle of the allocated block). This is called a "leak" by Dr. Memory, as there is no way for the application to free this memory: it has lost any handle it had to the memory.
3. Memory that is reachable only via pointers to the middle of the allocation, rather than the head. This is called a "possible leak" by Dr. Memory. These may or may not be legimitate pointers to that allocation.

Was kritisch ist sind bei langlebigen Programmen die Leaks die zu einem ständigen Zuwachs führen. Ich hatte da mal eins das wirklich nur wenige Bytes pro Minute geleaked hat. Nach ein paar Tagen kommt da natürlich eine auffallende Menge zusammen. Aber wenn man das debuggen will, möchte man nicht erst Tage warten. D.h. ich will dann nur wissen was zwischen einem Programmzustand A und einem Zustand B hinzugekommen ist. Das ganze Gerassel was davor passiert ist interessiert mich dann nicht (in dem würde mein kleines Leak sich ja nicht mehr auffallen).

Richtig; wie gesagt: Bei Dr. Memory läuft fast alles über die Suppressions. Aber du kannst wohl genau das über -nudge (siehe hier) erreichen. Ich habe es nicht ausprobiert, daher keine Garantien von mir.

Es geht mir nicht darum Werbung für UMDH zu machen. Mich würde nur interessieren ob Dr. Memory denn wirklich die Features hat die für mich unverzichtbar sind. Aus einer Aussage wie "an Dr. Memory kommt kein anderes heran" geht das nicht eindeutig hervor :)

Ebenfalls ohne Werbung machen zu wollen gibt dir Dr. Memory Warnungen für:

• Schreib- oder Lesezugriffe auf nicht-allokierten Speicher (unaddressable access)
• Lesezugriffe auf allokierten Speicher, der nicht initalisiert wurde (uninitialized read)
• Ungültige Benutzung der Heap-Funktionen new und delete, new[] und delete[], malloc und free, und die Debug-Versionen der letzten beiden (invalid heap argument)
• Wie gesagt: Speicherlecks

Diese Features, die es auf anderen Platformen in der Regel mit Valgrind gibt, gibt es sonst unter Windows meines Wissens nach überhaupt nicht. Und zum Jammern: Ja, es braucht die Release-CRT und funktioniert nur für x86-Anwendungen. Was es genau macht, kannst du hier nachlesen; die stecken wirklich verdammt viel Aufwand in die Code-Instrumentierung.

[Sternmull]

Hm. Für die Zusatzfeaturs die du aufzählst hat mir der Debug-Build von MSVC bisher eigentlich ausreichend gute Dienste geleistet.

Die -nudge Option für Dr. Memory hatte ich schon in der Doku entdeckt. Aber mein grundlegendes Problem wird dadurch nicht behoben: Soweit ich das verstehe werden dann trotzdem alle Allokationen aufgelistet die seit Start des Programms gemacht und noch nicht freigegeben wurden.

Die "erlaubten Leaks" manuell in einer Datei aufzulisten kommt mir äußerst fragwürdig vor (oder war das nicht so gemeint?). Der Dr. Memory sollte da meiner Meinung nach das Gleiche machen wie ich es von UMDH kenne: Dem Nutzer erlauben die Allokationen zu verschiedenen Zeitpunkten aufzulisten und sie dann nachträglich zu vergleichen um die Differenz anzuzeigen.

Das manuell machen zu müssen ist nun wirklich kein Feature.

EDIT: Dr. Memory nur mit Release CRT? Oh. In unserem Releasebuild kann man aufrgrund der Optimierungen nicht vernünftig debuggen (Funktionen werden zusammengefasst, Stacktrace verkrüppelt). D.h. wir müssten dann einen separaten unoptimierten Release-Build machen. Da bin ich jetzt nicht unbedingt scharf drauf.