Destruktor-Aufruf führt zu SIGILL
-
Ist es denn überhaupt möglich Stack Objekte als Kind in einem Qt Objekt zu haben.
Normalerweise tut man das ja nicht, da Qt selber immer den Speicher aufräumt.
-
Quelle war dieser Link hier: http://comments.gmane.org/gmane.comp.lib.qt.general/33444
edit: Und ja, das war wohl eine Fehlinformation. Zu früh gefreut.
-
Leider erzeugt das aber ein SIGILL. Die Stacktrace zeigt dabei auf die beiden Zeilen, die ich oben mit einem Sternchen markiert habe,also auf der untersten Ebene auf die geschlossene Klammer (!) am Ende des Destruktors!
Das heißt eigentlich, das der Fehler bei automatischem code nach dem destruktor aufgetreten ist. Normalerweise irgendein destruktor, der noch ausgeführt wird. Spontan seh ich da jetzt keinen direkten schuldigen, aber ich würd mir eventuell
QList<MapTile> map;anschaun, das ist der einzige Kandidat den ich auf den ersten blick als schuldigen sehe (außer du hast deinen destruktor noch etwas reduziert, denn du gepostet hast)
-
Wie gesagt, meine Klasse hat keinen expliziten Destruktor mehr. Trotzdem tritt noch ein Fehler in Level::~Level() auf.
-
Nicht "in" - "danach", also nach Level::~Level().
Deswegen ist der cursor auch am Ende der geschweiften Klammer, und nicht bei einer Code-Zeile im D-Tor, würd ich mal behaupten.
-
Taschenschieber schrieb:
Wie gesagt, meine Klasse hat keinen expliziten Destruktor mehr. Trotzdem tritt noch ein Fehler in Level::~Level() auf.
Einfache klare Frage:
hast du Kinder die auf dem Stack angelegt werden?
-
Level hat Member, die auf dem Stack angelegt werden, diese sind aber keine Kinder von Dungeon.
-
kleiner Troll schrieb:
Nicht "in" - "danach", also nach Level::~Level().
Deswegen ist der cursor auch am Ende der geschweiften Klammer, und nicht bei einer Code-Zeile im D-Tor, würd ich mal behaupten.Nee. Es ist normal, dass der Cursor im Callstack auf der nächsten Anweisung steht.
-
Taschenschieber schrieb:
Level hat Member, die auf dem Stack angelegt werden, diese sind aber keine Kinder von Dungeon.
Das war nicht die Frage.
Du läufst irgendwann in ein deleteChildren() rein. dh du hast irgendwo ein Objekt dem du Kinder gegeben hast. zB indem du setParent() für das Kind aufgerufen hast.Und die Frage ist ob du hier uU Stack Objekte als Kind verwendest. Denn deleteChildren() schlägt idR nur dann fehl, wenn es ein delete auf ein Stack Objekt macht.
Welche Member deine Objekte haben ist dabei nicht wichtig. Die Frage ist nur, kann ich das Objekt per delete löschen.
-
Laut seiner Deklaration von der ersten Seite kommt für diesen Effekt eigentlich nur noch MapTile infrage. Er hat ja keine von QObject abgeleiteten Member.
-
Der Typ MapTile ist übrigens ein enum. Die Tiles sind also auch eher unschuldig.