ich lerne gerade C++ in Kombination mit Qt (dementsprechend bin ich auch hier neu). Gerade bereitet mir dabei ein ziemlich komischer Fehler Kopfzerbrechen:

Mein C++-Programm hat eine Klasse Level. Diese Klasse hat einen Destruktor, der wie folgt definiert ist:

Level::~Level()
{
    delete [] map;
    delete [] fogOfWar;
} // (*)

map ist ein char-Array, fogOfWar ist ein bool-Array.

Eine andere Klasse (Dungeon) hat ein Member, das wie folgt definiert ist:

Level*          currentLevel;

Auf diesen Pointer greife ich in einer Memberfunktion der Klasse Dungeon wie folgt zu:

Q_ASSERT(currentLevel);

            if(currentLevel)
                delete currentLevel; // (*)
            currentLevel = new Level(currentLevelID, this);

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!

Darauf kann ich mir leider absolut keinen Reim machen - wie kommt dieser Fehler zustande, was könnte da das Problem sein? Das meiste, was ich zu diesem Problem ergooglet hatte, hatte irgendwas mit Assemblercode zu tun (gibt es bei mir nicht).

Noch ein paar Infos: Level erbt aus QObject (und erhält auch das dazugehörige Q_OBJECT-Makro), ich habe allerdings keine Ahnung, ob das mit dem Fehler zusammenhängt (bin noch ziemlicher Anfänger in C++).

Wenn ich alles in Level::~Level auskommentiere (also nur noch den Funktionskopf dastehen habe), tritt der Fehler weiterhin mit exakt dem gleichen Stack auf.

Weiteren Code kann ich auch gerne posten, ist allerdings ziemlich groß und ich habe keine Ahnung, was da interessant wäre und weiterhelfen würde.

Über Hilfe würde ich ich freuen.

Gruß,
Stephan

Aber all die Probleme sparst du dir, wenn du std::vector nutzt. Dein für die Speicherverwaltung nötiger Code wird dann nicht 50 Zeilen lang, sondern nur Null.

Und bei mehreren Feldern in der Klasse, musst du das strenggenommen sowieso in RAII-Unterklassen (wie eben std::vector) auslagern, um auch im Konstruktor Exceptionsicher zu sein.

QObjects löschen ihre Kinder, wenn sie gelöscht werden. Pass auf, dass du keinen double free bekommst. Normal muss man QObjects nicht selber löschen.

Öh, der Aufruf von "delete currentLevel" ist nicht aus dem Destruktor von Dungeon (der Dungeon ist Parent des Levels), sondern aus einer Funktion, die einen neuen Level erzeugt und den alten "entsorgt". Dabei wird dann auch der Pointer überschrieben.

Es wäre natürlich möglich, den alten Level nicht zu löschen und zu warten, bis er beim Programmende entfernt wird (der Dungeon wird erst bei Programmende gelöscht), das würde aber den Arbeitsspeicher zumüllen und kommt mir unsauber vor. Gibt es da eine elegantere Methode?

Q_ASSERT(currentLevel);

    if (currentLevel)
    {
        currentLevel->setParent(0); // <----------
        delete currentLevel;
        currentLevel = 0;
    }

    currentLevel = new Level(currentLevelID, this);

EDIT: OK, wenn ich so drüber nachdenke... wenn das was hilft, dann macht die Qt was verkehrt. Anders gesagt: wird wohl vermutlich nix bringen

if (currentLevel)

und im nächsten Schritt zerstörst du ein Objekt, das noch gar nicht existiert -> BUMM!
BTW.: wenn du diese Objekte eh selber managest, warum dann einen parent angeben? Lass den doch einfach weg.
Und nein, Qt ist nicht so dumm. Wird ein QObject zerstört, versucht der parent NICHT, dieses nochmal zu löschen.

Den parent brauche ich eh, da läuft nicht nur die Qt-Objektverwaltung drüber. So gesehen schadet das dann auch nicht.

Gestern hatte ich auf QLists umgestellt und den Destruktor entfernt (Regel der 3 eingehalten), der Fehler war aber beim delete-Aufruf immer noch da.

Hier mal meine Klassendefinition (level.h):

class Level : public QObject
{
Q_OBJECT
public:
    explicit        Level(int level, QObject *parent = 0);

    int             getWidth();
    int             getHeight();
    //MapTile*        getMap();
    MapTile         getMapAt(int x, int y);
    void            setMapAt(int x, int y, MapTile value);
    void            connectRooms(const QRect *, const QRect *);
    bool            canGoTo(int x, int y);
    bool            canGoTo(int oldX, int oldY, Direction direction);

    QPoint          getPlayerSpawningPoint();
    QPoint          getRandomEmptySpace();
    QPoint          getRandomSpawningPoint();

    void            clearFogOfWar(int posX, int posY);

    //bool          hasEnemyAt(int x, int y);
    Enemy*          getEnemyAt(QPoint location);
    QList<Enemy*>*  getEnemies();

    QList<Action>   possibleActionsAt(int x, int y);

signals:
    void            fogOfWarCleared(int x, int y);

public slots:
    void            characterMoved(int x, int y);
    void            dropFogOfWar(); // completely drops FoW
    void            removeDeadEnemy(Enemy* enemy);

private:
    QList<MapTile>  map;
    QList<bool>     fogOfWar;

    int             height;
    int             width;
    bool            isConnected();
    void            analyzeConnections(int,int, bool*);

    inline MapTile  getInternalMapAt(int x, int y);
    QList<Enemy*>   enemies;
};

Die Implementierung würde den Rahmen etwas sprengen (sind fast 500 Zeilen), wenn's weiterhilft, kann ich den Code aber auch gerne noch posten...

Die Implementierung würde den Rahmen etwas sprengen (sind fast 500 Zeilen), wenn's weiterhilft, kann ich den Code aber auch gerne noch posten...

Es würde weiterhelfen wenn du deine Implementierung auf das Wesentliche reduzierst - so dass man ein übersetzbares Programm erhält, bei dem der Fehler immernoch auftritt.

Es würde weiterhelfen wenn du deine Implementierung auf das Wesentliche reduzierst - so dass man ein übersetzbares Programm erhält, bei dem der Fehler immernoch auftritt.

Und dabei würde es mir wiederum weiterhelfen, überhaupt mal zu wissen, was eigentlich mögliche Ursachen für einen SIGILL sind. Ansonsten wird das wohl ziemliches Gestocher im Nebel.

Leider sind alle Google-Treffer, die ich zu diesem Thema bisher hatte, mehr als vage und klingen eher danach, als würde dieses Signal eigentlich nur bei Compilerfehlern und Rumgespiele mit laufzeitgenerierten Funktionen auftreten (also Casts eines int-Arrays in eine Funktion und so Späße), andere potentielle Ursachen habe ich beim Googlen nicht gefunden. Also was wären denn mögliche Fehlerquellen, die sich nicht in einem SIGSEGV, sondern in einem SIGILL äußern? (Compiler ist G++4.4.3 unter Windows 7, 64bit)

pumuckl schrieb:

Es würde weiterhelfen wenn du deine Implementierung auf das Wesentliche reduzierst - so dass man ein übersetzbares Programm erhält, bei dem der Fehler immernoch auftritt.

Und dabei würde es mir wiederum weiterhelfen, überhaupt mal zu wissen, was eigentlich mögliche Ursachen für einen SIGILL sind. Ansonsten wird das wohl ziemliches Gestocher im Nebel.

Steht da nicht mehr bei? Oft steht da was über die Ursache. Wenn du es eingestellt hast, bekommt du sogar einen Coredump. Vielleicht versteckt deine Umgebung diese Details vor dir, aber sie sind bestimmt irgendwo zu finden.

SIGKILL ist jedenfalls ein ziemlich hefitges Signal und wird vom Betriebssystem nur in Ausnahmefällen geschickt, zum Beispiel wenn der Kernel ganz dringend Arbeitsspeicher braucht und quasi einen Prozess zu Gunsten der Allgemeinheit opfern muss (ja, es geht rau zu in der Prozesswelt ). Sofern solche Ausnahmefälle nicht vorliegen, sollte das Signal von einem anderen Programm stammen. Vielleicht eine IDE oder ein Debugger, in denen das Programm läuft? Die sollten das dann natürlich irgendwo melden, aber da musst du natürlich erst nach suchen. Falls es doch das Betriebssystem ist, was das schickt, sollte es eine Nachricht in seine Logdateien schreiben. Wie schon gesagt, ist ein automatisches SIGKILL eine heftige Aktion, das passiert nicht mal eben so.

Immerhin hat der Threadersteller nun auch eine Erklärung zu SIGKILL, wenn er ihm mal begegnet und die Wikipediaseite erklärt die Ursachen von SIGILL.

edit: Ich empfehle übrigens mal valgrind mit allen Tests auf das Programm loszulassen. Und.oder sich mal einen Coredump anschauen. Oder im Debugger schauen, warum genau die Anweisung fehlschlägt.

Der Debugger hat sich aber doch noch erbarmt, ein paar mehr Details auszugeben, und zwar zeigt der Stack hierhin:

#0  0x0f543180 in ?? ()
No symbol table info available.
#1  0x6a225b5e in QObjectPrivate::deleteChildren (this=0xf4d4638) at kernel\qobject.cpp:1908
        i = 1
        reallyWasDeleted = true
#2  0x6a223bde in QObject::~QObject (this=0xd0921d8, __in_chrg=<value optimized out>) at kernel\qobject.cpp:927
        d = 0xf4d4638
#3  0x00420e80 in Level::~Level (this=0xd0921d8, __in_chrg=<value optimized out>) at debug//../level.h:38
No locals.

Die genaue Fehlermeldung im Debugger ist "Illegal instruction (Signal SIGILL)".

Und mit Eingabe des Funktionsnamens "QObjectPrivate::deleteChildren" (der mir bisher wirklich noch nicht aufgefallen war...) weiß auch Google eine Lösung: Level hat Kinder, die auf dem Stack anstatt auf dem Heap angelegt werden - diese werden gelöscht, wenn der Scope abläuft, aber der Parent versucht trotzdem noch, das Kind zu entfernen, wenn der Parent gelöscht werden soll. Dabei tritt dann verständlicherweise ein Fehler auf.

Mal gucken, ob ich das Problem mit dieser Erkenntnis gelöst kriege. Danke jedenfalls an alle Helfer.

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.

Einfache klare Frage:
hast du Kinder die auf dem Stack angelegt werden?

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.

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.