3. Problem mit Speicherfreigabe bei Programmabbruch

Problem mit Speicherfreigabe bei Programmabbruch

  • ?

    In dem Fall müsstest du mal relevanten Code posten.
    - Welchen Speicher reservierst du
    - wo / wann gibst du ihn wieder frei ( oder versuchst es zumindest )

    Wenn du glaubst, dass es nix mit QT zu tun hat, dann schreib das am besten garnicht erst hin, sondern poste gleich den Code, wo du den Fehler vermutest.

    0
  • _

    Grundsätzlich gilt: zu jedem new/new[] gehört genau ein delete/delete[]. Aber wie bereits gesagt wurde, poste erst mal ein wenig Code, dann sehen wir weiter.

    0
  • X

    Kann gerne ich machen. Das Programm ist allerdings etwas größer und ich muss erstmal die entsprechenden Teile raussuchen und zu einem kleinem Testprogramm zusammenbauen. Ich weiß nicht ob ich vor dem Wochenende dazu komme.
    Daher bitte nicht wundern wenn ich mich ein paar Tage nicht melde.

    0
  • R

    Wenn ich mich richtig erinnere läufts ja so ab, dass ein Objekt von QApplication erzeugt wird, dem weist du dann ein Objekt deiner Windowklasse zu und führst das ganze schließlich mit exec aus.

    Irgendwie so sollte das jedenfalls laufen.

    Das Problem ist dass die Konsole den Hauptthread deines Prozesses darstellt, also auch den in dem dein QApplication Objekt arbeitet. Wenn du die Konsole schließt killst du diesen und deine Qt-Applikation hat nicht genug Zeit noch alles aufzuräumen bevor Windows dem ganzen den Todesstoß verpassen will

    Mir fallen auf Anhieb nur plattformabhängige Lösungen ein:

    Die einfachste ist das Konsolenfenster verschwinden lassen:

    #include <windows.h>

//....

HWND hwnd;

hwnd = GetConsoleWindow(); // siehe da: http://msdn.microsoft.com/en-us/library/ms683175.aspx

if( hwnd )
	ShowWindow( hwnd, SW_HIDE );

    Eine Andere wäre irgendwie zu versuchen die Message abzufangen die der Konsole mitteilt dass sie geschlossen wird, dürfte aber wesentlich schwieriger sein.

    0

  • Soweit ich weiss läuft das Beenden mittels "X" bei Konsolen-Applikationen über ein "signal" (vermutlich SIGTERM). Setz den Handler über die "signal" Funktion und tu im Handler was auch immer nötig ist um dein Programm sauber zu beenden.
    Alternativ kannst du, wenn es "nichts ausmacht" den Prozess im Signal-Handler auch einfach mit ExitProcess "abschiessen".

    0
  • T

    _matze schrieb:

    Grundsätzlich gilt: zu jedem new/new[] gehört genau ein delete/delete[]. Aber wie bereits gesagt wurde, poste erst mal ein wenig Code, dann sehen wir weiter.

    Und gerade das ist bei Qt (leider) nicht so. Bei Qt werden zwar die meisten Objekte mit new angelegt (müssen sie sogar), um die Freigabe kümmert sich aber das Framework. Man baut sich Parent-Child-Bäume auf, und wenn Parents zerstört werden, werden auch die abhängigen Childs zerstört.
    Deshalb knallen einem Programme die statische Qt-Widgets anlegen auch so toll um die Ohren, und das ist auch einer der Gründe, wieso ich Qt etwas komisch finde.
    Ohne Code schwer zu sagen, aber ich vermute mal, dass Du etwas löscht, das Qt bereits gelöscht hat, oder das Qt versucht etwas zu löschen, dass Du selbst bereits gelöscht hast.

    0

  • @Tachyon: ich dachte immer QT verwendet Ref-Counting. In dem Fall könnte man statische Objekte am Leben halten, indem man einfach 1x AddRef aufruft.

    0
  • T

    hustbaer schrieb:

    @Tachyon: ich dachte immer QT verwendet Ref-Counting. In dem Fall könnte man statische Objekte am Leben halten, indem man einfach 1x AddRef aufruft.

    Es heisst Qt, nicht QT 🤡 .
    Ist das so? Meines Wissens hat Qt dieses Verhalten. Ich sehe aber gerade, dass Qt Child-Objekte von den Parents entfernt, wenn man sie Childs selbst löscht. Ich denke aber, wenn man versucht die Childs löscht, nachdem der Parent gelöscht wurde, gibts trotzdem Fehler.

    0

  • Oops, doch kein Ref-Counting, da hatte ich grossen Blödsinn in Erinnerung 🙂

    0
  • X

    Danke für die Hinweise 🙂

    Ich habe mich heute nochmal drangesetzt und denke den Fehler gefunden zu haben. Wie ich vermutet hatte lag das Problem nicht an Qt.
    Ich hatte aus Debug zwecken eine Textausgabe im Destruktor einer Klasse. Von dieser Klasse habe ich einem Programm nun ein statisches Objekt angelegt. Wenn ich das Programm normal beendet habe ging es ohne Probleme und wenn ich das Fenster geschlossen habe kam es zu einer Fehlermeldung.

    Letztendlich hatte ich sowas:

    #include <iostream>

class MyClass {

public:
	MyClass() {
		std::cout << "Konstruktor" << std::endl;
	}

	~MyClass() {
		std::cout << "Destruktor" << std::endl;
	}
};

int _tmain(int argc, char* argv[]) {

	static MyClass myClass;

	char c;
	std::cin >> c;

	return 0;
}

    Wenn ich das Beispielprogramm beende indem ich etwas eingebe und Enter drücke ist alles gut. Wenn ich das Fenster schließe bleibt es hängen.
    Sobald ich die Textausgabe im Destruktor entferne oder das static weg mache geht es.
    cout scheint also nicht mehr zu existieren wenn der Destruktor aufgerufen wird.

    mfg xorm :xmas2:

    0
Anmelden zum Antworten