2009-06-17 5 views
1

Ich baue eine Qt 4.5-Anwendung unter Windows mit Visual Studio 2008. Wenn ich meine Anwendung im Debug-Modus ausführen und dann schließen, druckt Visual Studio die im Anschluss an das Ausgabefenster:Beim Schließen einer Qt 4.5-Anwendung meldet Visual Studio, dass es Speicherlecks erkannt hat

Erkannte Speicherlecks!
Dumping Objekte ->
{696512} normalen Block bei 0x01981AB0, 24 Bytes lang.
Daten: <> 00 CD CD CD 00 00 00 00 00 00 00 00 00 00 00 00
{696511} normaler Block bei 0x02E59B70, 12 Bytes lang.
Daten: < U2g U2g> B0 1A 98 01 E8 55 32 67 E8 55 32 67

Und die Ausgabe berichtet Hunderte solcher Blöcke. Ich habe dies besonders bei der Verwendung des Model/View-Frameworks von Qt 4 bemerkt. Hat Qt tatsächlich Speicherlecks oder gibt es Umstände, unter denen Visual Studio Lecks falsch ausgibt?

+6

Möglicherweise gibt es auch die Möglichkeit, dass Ihr Code Speicherlecks hat ... – sth

+0

Befreien Sie jede zugeordnete Ressource oder lassen Sie den Prozess einfach (in diesem Fall ist das Leck von Design - in der Regel aus Leistungsgründen)? –

+1

Einer der Speicher "Gotcha" s Ich habe Leute gesehen ist, dass Modelle nicht von der Ansicht gehören. Es wäre in den meisten Fällen nicht sinnvoll, sie in Besitz der Ansicht zu haben, aber wenn Sie nicht darüber nachdenken, glauben Sie vielleicht, dass das Festlegen eines Modells für eine Ansicht die Ansicht als das übergeordnete Element des Modells festlegt. Dies könnte Speicherlecks verursachen. –

Antwort

2

ich eine Chance hatte mein Projekt zum Profil DevPartner verwenden. Das Überraschende ist, dass es Speicherverluste in QtGuid4.dll und QtCored4.dll meldet; Nachdem ich jedoch jeden Fall manuell betrachtet hatte, stellte ich fest, dass es sich um falsch positive Ergebnisse handelte.

Als eine Nebenbemerkung wurden keine Speicherverluste im Code mit Qt gemeldet.

1

Stellen Sie sicher, dass Sie dynamischen Speicher in Qt-way verwenden, z.

#include <QObject> 
#include <QString> 

class MyClass : public QObject 
{ 
public: 
MyClass (const QString& text, QObject *parent = 0); 
... 
}; 


int main() 
{ 
QObject parent; 
MyClass *a; 
a = new MyClass ("foo", &parent); 
... 
} 

(c) Johan Thelin, "Grundlagen der Qt Development"

+0

@MadH: Ja, ich habe alle Qt-Objekte richtig parented, wie Sie erwähnt haben. Für Klassen, die QObject nicht erben, verwende ich Boost Smart Pointer. Ich habe also nur eine Handvoll Objekte, deren Erinnerung ich selbst manage. – Krsna

+0

@Krsna dann wäre es interessant, die Antwort zu wissen ;-) – MadH

4

Der Infospeicherleck wird durch die Debug-Fenster Laufzeit zur Verfügung gestellt. Ihr Programm kann interagieren und dies konfigurieren.

Die Nummer in geschweiften Klammern {696512} ist die Zuordnungsnummer. Wenn diese Nummer immer gleich ist, können Sie einen Unterbrechungspunkt für diese Zuordnung festlegen, indem Sie die Nummer an _CrtSetBreakAlloc übergeben. Führen Sie das Programm erneut in dem Debugger aus, und der Debugger wird beendet, wenn der ausgelöffte Speicher reserviert ist.

Diese Funktion früh in main aufrufen. Wenn die Nummer nicht immer identisch ist, versuchen Sie das Speicherleck mit reduziertem Code zu reproduzieren, bis es immer gleich ist.

Weitere Informationen finden Sie Memory Leak Detection Enabling

0

Ich denke, das passiert, wenn der Speicherlecksucher auf Lecks prüft, bevor QT es aufräumt. Ich behob dieses Problem, indem ich meine qtmaind.lib, QtCored4.lib, QtGuid4.lib, QtOpenGLd4.lib, etc. zum unteren Teil des Linker-Abhängigkeiten-Felds im VS-Projekteinstellungen-Dialog bewegte.