finde das Speicherleck nicht

pospiech

ich habe folgendes gefunden, aber das soll nur für pures C gelten und erzeugt bei mir auch gar keine Ausgabe:
http://msdn.microsoft.com/en-us/library/e5ewb1h3.aspx

The primary tools for detecting memory leaks are the debugger and the C Run-Time Libraries (CRT) debug heap functions. To enable the debug heap functions, include the following statements in your program:
Copy Code
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

_CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF);

ganz am anfang deiner main() bzw. WinMain() einfügen. funktioniert natürlich nur im debug-build!

pospiech schrieb:

aber das soll nur für pures C gelten

nein, das hast du falsch verstanden.

pospiech

naseweis schrieb:

_CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF);
ganz am anfang deiner main() bzw. WinMain() einfügen. funktioniert natürlich nur im debug-build!

folgendes Kompiliert bei mir allerdings nicht:

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

_CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF);

int main(int argc, char** argv)
{

1>.\src\main.cpp(8) : error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt.
1>.\src\main.cpp(8) : error C2365: "_CrtSetDbgFlag": Erneute Definition; vorherige Definition war "Funktion".
1> C:\Programme\Microsoft Visual Studio 8\VC\include\crtdbg.h(981): Siehe Deklaration von '_CrtSetDbgFlag'

naseweis schrieb:

pospiech schrieb:

aber das soll nur für pures C gelten

nein, das hast du falsch verstanden.

kann ich nicht beurteilen, steht so im Kommentar unten auf der Seite.

lies ein anfängertutorial.

drakon

pospiech schrieb:

...

In die main.. Du machst da einen Funktionsaufruf vor der main..

pospiech

naseweis schrieb:

lies ein anfängertutorial.

zu was? Compiler Macros von Visual Studio/Microsoft? Nicht sehr hilfreich so ein Hinweis.

EDIT:

drakon schrieb:

pospiech schrieb:

...

In die main.. Du machst da einen Funktionsaufruf vor der main..

Ja klar. Danke für den Hinweis. Ich arbeite normalerweise nie innerhalb von main.cpp...

Es wird übrigens mit dem code im debug Modus nie eine Ausgabe erstellt.

startest du das programm im debugger? schaust du dir den inhalt des ausgabefensters an?

drakon

pospiech schrieb:

Ja klar. Danke für den Hinweis. Ich arbeite normalerweise nie innerhalb von main.cpp...

Das hat mit dem nichts zu tun. Du hast einen Funktionsaufruf ausserhalb einer Funktion gemacht und das geht nun mal einfach nicht.

pospiech

naseweis schrieb:

startest du das programm im debugger? schaust du dir den inhalt des ausgabefensters an?

Ja. Ich schaue mir im Teilfenster 'Ausgabe' den Tab 'Ausgabe' an, der nach dem Starten des Programms folgendes enthält:

"ModelockingSimulationd.exe": "C:\Programme\Trillian\events.dll" geladen, Keine Symbole geladen.
"ModelockingSimulationd.exe": "C:\Programme\Trillian\msvcr71.dll" geladen, Keine Symbole geladen.
Der Thread 'Win32 Thread' (0xd7c) hat mit Code 0 (0x0) geendet.

die leaks werden erst beim beenden des programms ausgegeben. ansonsten fällt mir nix weiter ein, es müsste so eigtl. funktionieren.

pospiech

naseweis schrieb:

die leaks werden erst beim beenden des programms ausgegeben. ansonsten fällt mir nix weiter ein, es müsste so eigtl. funktionieren.

Dann steht da auch nicht viel mehr.

R3dNeXX

dann muss ich da mal blöd fragen: Woher weißt du denn, dass deine Applikation Leaks hat ??

Wenn im Output nix steht, dann dürfte es eigentlich keine Leaks geben (glaub ich zumindest )

Nexus

Bau doch mal ein Leak ein, zum Beispiel

new double;

Dann müsste dort nachher stehen "Leaks detected! 8 Byte in Zeile .." oder so ähnlich.

pospiech

R3dNeXX schrieb:

dann muss ich da mal blöd fragen: Woher weißt du denn, dass deine Applikation Leaks hat ??

weil sie mit jedem Plot (jede Sekunde) ca. 2 MB Speicher verbraucht und dieser Verbrauch steil nach oben geht. In wenigen Minuten kommen da 100te von MB zusammen.

Folgender Code liefert mir noch immer keine Ausgabe:

//#include <qt/qapplication.h>
//#include "MainWindow.h"

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

int main(int argc, char** argv)
{
	_CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF);

	//QApplication app( argc, argv );

	//// create a new instance of MainWindow
	//MainWindow mainWindow;	
	//mainWindow.show();

	//// Enters the main event loop and waits until exit() is called 
	//// or the main widget is destroyed, and Returns the value that 
	//// was set via to exit() (which is 0 if exit() is called via quit()). 
	//return app.exec();

	double * abc = new double;
}

Nexus

Schreib nach #include <crtdbg.h> Folgendes:

#define new new(_NORMAL_BLOCK, __FILE__, __LINE__)

Zudem kannst du _CrtSetDbgFlag() noch das Flag _CRTDBG_ALLOC_MEM_DF übergeben.

pospiech

Ok, das geht jetzt:

define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#define new new(_NORMAL_BLOCK, __FILE__, __LINE__)

int main(int argc, char** argv)
{
	_CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF | _CRTDBG_ALLOC_MEM_DF);

	double * abc = new double; 
}

liefert mir

Detected memory leaks!
Dumping objects ->
.\src\main.cpp(24) : {138} normal block at 0x003F6B98, 8 bytes long.
Data: < > CD CD CD CD CD CD CD CD
Object dump complete.

Wenn ich das im eigentlichen Programm laufen lasse. Also im einfachsten Fall dieses einmal starte und direkt wieder beende, dann bekomme ich eine sehr lange Liste von solchen Lecks.

Wie kann ich mir anzeigen lassen zu welchen Dateien / Variablen die gehören?

Nexus

pospiech schrieb:

Wie kann ich mir anzeigen lassen zu welchen Dateien / Variablen die gehören?

Du siehst ja, in welcher Zeile und welcher Datei das Leak aufgetreten ist, dann kannst du den Fehler dort suchen.

pospiech

Nexus schrieb:

pospiech schrieb:

Wie kann ich mir anzeigen lassen zu welchen Dateien / Variablen die gehören?

Du siehst ja, in welcher Zeile und welcher Datei das Leak aufgetreten ist, dann kannst du den Fehler dort suchen.

Ich sehe weder Datei noch Zeile:

Detected memory leaks!
Dumping objects ->
{162014} normal block at 0x00B2F740, 60 bytes long.
Data: < > 12 00 00 00 12 00 00 00 12 00 00 00 12 00 00 00
{144095} normal block at 0x00E72FF8, 24 bytes long.
Data: < > 01 00 00 00 02 00 00 00 00 00 00 00 01 00 00 00
{162015} normal block at 0x00E6E420, 60 bytes long.
Data: < > 00 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00
{103487} normal block at 0x00E62910, 480 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{103486} normal block at 0x00E62740, 400 bytes long.
...

EDIT: Das ursprüngliche Problem habe ich nach manuellem Suchen nach new Anweisungen auch finden können. Es fehlte, wie zu erwarten, ein delete.
Und es hatte auch nichts mit dem Code zu tun, den ich gepostet hatte.

drakon

Ich fürchte, dass das etwas schwieriger ist die genaue Zeile rauszukriegen. Du musst halt behutsam vorgehen und immer mal wieder auf die Ausgabe schauen, wenn du dein Programm testest, dann solltest du eigl. immer Wissen, wo im Code ein Leck möglich ist.

pospiech

drakon schrieb:

Ich fürchte, dass das etwas schwieriger ist die genaue Zeile rauszukriegen. Du musst halt behutsam vorgehen und immer mal wieder auf die Ausgabe schauen, wenn du dein Programm testest, dann solltest du eigl. immer Wissen, wo im Code ein Leck möglich ist.

Da diese Ausgabe erst nach dem Beenden des Programms generiert wird ist das schlecht möglich.