finde das Speicherleck nicht

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.

drakon

pospiech schrieb:

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.

Naja. Wenn man plötzlich ein Leck hat, welches vorher noch nicht da war, dann hat das mit grosser Wahrscheinlichkeit damit zu tun, was du in den letzen paar Zeilen Code getan hast.
Wenn nicht, dann kann man auch noch einen richtigen Leak Detector zur Hand nehmen.

Nexus

Verwendest du da das Makro new falsch? Denn dass keine Informationen über Zeile und Datei vorhanden sind, scheint mir komisch.

Prüf doch mal nach, ob wirklich die Version von new mit den drei Parametern aufgerufen wird. Wenn das in einer anderen Übersetzungseinheit steht, könnte es komplizierter werden...

pospiech schrieb:

{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

CrtSetBreakAlloc(162014) erzeugt einen breakpoint bei dieser allokation.