[Mem-Leaks] Wie kann man das interpretieren ?

don_basto

Habe folgende Ausgabe im Debugger:

'BlendingDemo.exe': 'C:\WINDOWS\system32\iccvid.dll' entladen
Detected memory leaks!
Dumping objects ->
{126} normal block at 0x010D64B0, 29 bytes long.
Data: < 2| > D8 9C 32 7C 0C 00 00 00 0C 00 00 00 01 00 00 00
f:\..\blendingdemo\blendingdemo.cpp(70) : {123} client block at 0x010D6258, subtype c0, 348 bytes long.
a CMainFrame object at $010D6258, 348 bytes long
oleinit.cpp(85) : {120} client block at 0x010D6160, subtype c0, 68 bytes long.
a CCmdTarget object at $010D6160, 68 bytes long
{115} normal block at 0x010D5F88, 12 bytes long.
Data: <<FD D > 3C 46 44 00 CE CD CD CD 44 00 00 00
{114} normal block at 0x010D5EE8, 93 bytes long.
Data: <f:\Quellkode\Cpp> 66 3A 5C 51 75 65 6C 6C 6B 6F 64 65 5C 43 70 70
Object dump complete.
Das Programm "[2640] BlendingDemo.exe: Systemeigen" wurde mit Code 3 (0x3) beendet.

Allerdings kommt das Speicherleck nur in der Debugversion. Hab mit dem Leakfinder von Jochen versucht den Fehler zu finden. Allerdings produziert der kein Output (Hab mich an den MFC-Quellkode gehalten).

Könnt ihr was aus der Debugger-Meldung rauslesen?

Danke,
don_basto.

// EDIT:
Da soll ein Fehler liegen:

// Dieser Code erstellt ein neues Rahmenfensterobjekt und setzt dieses
	// als das Hauptfensterobjekt der Anwendung, um das Hauptfenster zu erstellen.
	CMainFrame* pFrame = new CMainFrame;

Allerdings ist das automatisch generieter Kode.

Jochen Kalmbach

Wenn das Leak immer die gleiche Nummer hat (das was in geschweiften Klammern steht), kannst Du auch einfach ein Breakpoint bei dieser Nummer auslösen lassen. Dann kannst Du zumindest sehr einfach sehen, was genau allokiert wird.

http://msdn2.microsoft.com/w2fhc9a3.aspx

_CrtSetBreakAlloc(114);

don_basto

Bin jetzt soweit, dass nur noch der Fehler mit dem Mainframe kommt:

Detected memory leaks!
Dumping objects ->
{123} normal block at 0x010D6388, 38 bytes long.
Data: < 2| > D8 9C 32 7C 15 00 00 00 15 00 00 00 01 00 00 00
f:\..\blending\blendingdemonstration\blendingdemonstration.cpp(50) : {120} client block at 0x010D6120, subtype c0, 348 bytes long.
a CMainFrame object at $010D6120, 348 bytes long
Object dump complete.
Das Programm "[3636] BlendingDemonstration.exe: Systemeigen" wurde mit Code 3 (0x3) beendet.

Aber hab keinen Plan, wie ich das fixen kann.

Jochen Kalmbach

Rufst Du von Hand die Funktion "_CrtDumpMemoryLeaks" auf??? Das solltest Du tunlichst nicht machen!
Du solltest nur folgendes aufrufen:

_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

don_basto

@Jochen:
Ich mach gar nichts.
Das ist alles so voreingestellt. Hab den Leakfinder verwendet, der aber keine Ausgaben macht (es wird keine XML-Datei erzeugt). Hab ein neues Projekt erstellt und bis auf die BlendingDemonstration.h/-.cpp und die Mainfrm.h/-.cpp alles aus dem alten Projekt drübergebügelt und da komm wieder der Fehler, allerdings nur noch der mit dem Mainframe.

Jetzt hab ich deinen Tipp berücksichtigt, aber der Kompiler haut mir das um die Ohren (hab' einfach in BlendingDemonstration.cpp global hinzugefügt):

f:\..BlendingDemonstration\BlendingDemonstration.cpp(25): error C2501: '_CrtSetBreakAlloc': Fehlende Speicherklasse oder Typspezifizierer
f:\..\BlendingDemonstration\BlendingDemonstration.cpp(25): error C2365: '_CrtSetBreakAlloc': Erneute Definition; vorherige Definition war 'Funktion'

Da ich vom Debugger keine Ahnung hab, kann ich mit deiner letzten Frage nichts anfangen.

Jochen Kalmbach

#include <crtdbg.h>

don_basto

Hatte ich mir zuerst auch gedacht, hat aber nix gebracht ..
Die Fehler sind geblieben.

BTW: Wenn im Release keine Leaks angezeigt werden, sind dann keine da oder werden die nicht registriert?

Jochen Kalmbach

Im Release werden von der CRT keine Leaks aufgezeichnet, somit wird hier die CRT *nie* irgendwas anzeigen!
Um Leaks zu finden kannst Du auch UMDH verwenden (auch im Release)...
Siehe:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-135100-and-start-is-0-and-postdays-is-0-and-postorder-is-asc-and-highlight-is-umdh.html

don_basto

Ich komme nicht voran.

Das Hauptproblem scheint die Zerstörung des CMainFrame-Objekts m_pMainWnd, geerbt von CWinThread sein. Aber das sind doch im Grunde interne MFC-Angelegenheiten, mit denen ich als MFC-Anwender eigentlich nichts zu tun habe. Ich weiß wirklich nicht, wie bzw. wo ich diesen Fehler verursache.

Wie gesagt, habe ich die Dateien der Anwendung und das MainFrames aus einer neu generierten Anwendung nochmal drüberkopiert, aber der Fehler bleibt. Hier noch mal der Kode, welcher mir vom Debugger angezeigt wird:

BOOL CBlendingDemonstrationApp::InitInstance()
{
	CWinApp::InitInstance();

	// Standardinitialisierung

	// _JETZT_ kommt das Leck
	CMainFrame* pFrame = new CMainFrame;

	if (!pFrame)
		return FALSE;
	m_pMainWnd = pFrame;
	// Rahmen mit Ressourcen erstellen und laden
	pFrame->LoadFrame(IDR_MAINFRAME,
		WS_OVERLAPPEDWINDOW | FWS_ADDTOTITLE, NULL,
		NULL);
	// Das einzige Fenster ist initialisiert und kann jetzt angezeigt und aktualisiert werden.
	pFrame->ShowWindow(SW_SHOW);
	pFrame->UpdateWindow();
	// Rufen Sie DragAcceptFiles nur auf, wenn eine Suffix vorhanden ist.
	//  In einer SDI-Anwendung ist dies nach ProcessShellCommand erforderlich
	return TRUE;
}

Die Möglichkeiten über die <crtdbg.h> kann ich nicht einsetzen, da selbst bei einem unbearbeiteten neuen Projekt die oben beschriebenen Fehler kommen, unabhängig davon, ob ich den Header inkludiere oder nicht.

Der Link aus'm MSDN (http://msdn2.microsoft.com/w2fhc9a3.aspx) hilft mir nicht, da ich die Anleitung zum Einstellen des Debuggers nicht kapiere. Wenn ich einen Haltepunkt auf eine Adresse (mit "{,,msvcr71d.dll}_crtBreakAlloc")lege, finde ich nirgendwo eine Einstellmöglichkeit für einen Wert(bzw. "Value"). Hab's über Bedingung versucht, ist aber nix passiert.
Ich verwende VC7.1 deutsch.

Falls jemand eine Idee oder einen Ansatz hat, wie das Leck finden kann, bitte schreiben.

Jochen Kalmbach

Kannst Du ein kleines Projekt machen, wo dieser Effekt auftritt? Dann kannst Du mir dieses mal zukommen lassen...

don_basto

@Jochen:

Danke, das Angebot nehme ich an.

don_basto

Dank Jochen's Hilfe ist der Fehler gefunden. Das eigentliche Problem wird bei der Zerstörung der View ausgelöst, aber nicht mehr ordentlich angezeigt. Der Fehler lag in der Zerstörung des Timers:

CChildView::~CChildView()
{
	// ..

	//if (m_timer)
	//	KillTimer(m_timer);
}

Wenn ich es auskommentiere, läuft die Anwendung fast problemlos.

Danke @ Jochen. Allein wäre ich da nie drauf gekommen.

Bis dann,
don_basto.

Jochen Kalmbach

don_basto schrieb:

Danke @ Jochen. Allein wäre ich da nie drauf gekommen.

Bitteeee