Initialisierung mit Listen



  • Hallo,

    eine Frage zur "Initialisierung mit Listen" bei allgemeinen Konstruktoren: Ich habe eine Klasse:

    // .H-file
    #include <iostream>
    
    //! Definition of a mesh class.
    class mesh {
    public:
    
      mesh();
      ~mesh();
    ...
    
    private:
    
        int     numNodes_;
        int     numCells_;
        float*  materialvalueList_;
        CellPtr* cellList_;
        TCellPtr* tcellList_;
        EdgePtr* sourceList_;
    };
    

    und initialisiere diese:

    // .CC-File
    #include "mesh.h"
    mesh::mesh() : 
                       numNodes_(0),
                       numCells_(0),               
                       cellList_(0),
                       tcellList_(0),
                       sourceList_(0)
    { };
    

    wobei:

    typedef EdgeT*  EdgePtr;
    typedef CellT*  CellPtr;
    typedef TCellT* TCellPtr;
    

    definiert ist und die folgenden Klassen existieren:

    //---------------------------
    class EdgeT {
    public:
    
      EdgeT();
      EdgeT( int index1, int index2 );
      EdgeT( int index[] );
      ~EdgeT();
    ...
    private:
      int index_[2];
    };
    
    //---------------------------
    class CellT {
    public:
    
      virtual ~CellT() { }
    
    protected:
    
      CellT() { }
    };
    
    //---------------------------
    class TCellT : public CellT {
    public:
    
      TCellT();
     ~TCellT() { }
    
    private:
    
      int index_[4];
    };
    //---------------------------
    

    NUN: Tritt das Problem auf, dass der Ausdruck :

    sourceList_(0)

    in der Initialisierungsliste des Konstruktors folgende Fehlermeldung bringt:

    *** glibc detected *** ./exo: double free or corruption (!prev): 0x0000000000640010 ***
    ======= Backtrace: =========
    /lib64/libc.so.6[0x2ac6e0d668fe]
    /lib64/libc.so.6(cfree+0x76)[0x2ac6e0d67f36]
    ./exo(__gxx_personality_v0+0x233)[0x4019ab]
    /lib64/libc.so.6(__libc_start_main+0xf4)[0x2ac6e0d17ae4]
    ./exo(__gxx_personality_v0+0xa1)[0x401819]
    ======= Memory map: ========
    00400000-0043e000 r-xp 00000000 03:04 963722 /home/jochen/project/exodustest/exo
    0063e000-0063f000 r--p 0003e000 03:04 963722 /home/jochen/project/exodustest/exo
    0063f000-00640000 rw-p 0003f000 03:04 963722 /home/jochen/project/exodustest/exo
    00640000-006d2000 rw-p 00640000 00:00 0 [heap]
    2ac6e0379000-2ac6e0395000 r-xp 00000000 03:04 1093442 /lib64/ld-2.5.so
    2ac6e0395000-2ac6e0397000 rw-p 2ac6e0395000 00:00 0
    2ac6e03c9000-2ac6e03ca000 rw-p 2ac6e03c9000 00:00 0
    2ac6e0595000-2ac6e0597000 rw-p 0001c000 03:04 1093442 /lib64/ld-2.5.so
    2ac6e0597000-2ac6e067a000 r-xp 00000000 03:04 1260291 /usr/lib64/libstdc++.so.6.0.8
    2ac6e067a000-2ac6e087a000 ---p 000e3000 03:04 1260291 /usr/lib64/libstdc++.so.6.0.8
    2ac6e087a000-2ac6e0880000 r--p 000e3000 03:04 1260291 /usr/lib64/libstdc++.so.6.0.8
    2ac6e0880000-2ac6e0883000 rw-p 000e9000 03:04 1260291 /usr/lib64/libstdc++.so.6.0.8
    2ac6e0883000-2ac6e0895000 rw-p 2ac6e0883000 00:00 0
    2ac6e0895000-2ac6e08ea000 r-xp 00000000 03:04 1093457 /lib64/libm-2.5.so
    2ac6e08ea000-2ac6e0ae9000 ---p 00055000 03:04 1093457 /lib64/libm-2.5.so
    2ac6e0ae9000-2ac6e0aeb000 rw-p 00054000 03:04 1093457 /lib64/libm-2.5.so
    2ac6e0aeb000-2ac6e0af8000 r-xp 00000000 03:04 1093493 /lib64/libgcc_s.so.1
    2ac6e0af8000-2ac6e0cf7000 ---p 0000d000 03:04 1093493 /lib64/libgcc_s.so.1
    2ac6e0cf7000-2ac6e0cf9000 rw-p 0000c000 03:04 1093493 /lib64/libgcc_s.so.1
    2ac6e0cf9000-2ac6e0cfa000 rw-p 2ac6e0cf9000 00:00 0
    2ac6e0cfa000-2ac6e0e33000 r-xp 00000000 03:04 1093449 /lib64/libc-2.5.so
    2ac6e0e33000-2ac6e1032000 ---p 00139000 03:04 1093449 /lib64/libc-2.5.so
    2ac6e1032000-2ac6e1035000 r--p 00138000 03:04 1093449 /lib64/libc-2.5.so
    2ac6e1035000-2ac6e1037000 rw-p 0013b000 03:04 1093449 /lib64/libc-2.5.so
    2ac6e1037000-2ac6e103d000 rw-p 2ac6e1037000 00:00 0
    2ac6e4000000-2ac6e4021000 rw-p 2ac6e4000000 00:00 0
    2ac6e4021000-2ac6e8000000 ---p 2ac6e4021000 00:00 0
    7fffca71a000-7fffca731000 rw-p 7fffca71a000 00:00 0 [stack]
    ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso]
    Abgebrochen

    warum kann ich "cellList_(0),tcellList_(0)," initialisieren aber "sourceList_(0)" nicht? Was für Regeln gelten dabei?
    Danke für Hilfe!

    Jo



  • Reduzier das Beispiel mal auf ein Minimum - tritt der Fehler bereits im Ctor auf? Und hast du den Fehler schon, wenn du das Objekt anlegst und sofort aus dem Scope fallen lässt?



  • Zuerst einmal: nutze das Syntax-Highlighting, dann ist dein Code deutlich einffacher zu lesen.
    Dann: Du initialisierst einen Pointer auf TCellPtr, also einen Pointer auf einen Pointer mit 0 - das duerfte kein Problem sein. Der Fehler duerfte also ein etwas subtilerer Sein als dass einfach die Initialisierung dir so eine Fehlermeldung beschert.



  • Sobald ich "sourceList_(0)" auskommentiere gibt es kein Problem mehr!



  • Kommentier mal sämtlichen Code aus der sourceList_ benutzt und dann probiers nochmal.
    Meine Vermutung ist, dass der Code mit auskommentiertem sourceList_(0) nur deswegen läuft weil die Variable dadurch einen Wert != 0 hat und es so scheint als würde es funktionieren.



  • Ich habe alles was mit sourceList_ zutun hat auskommentiert.
    Nur in "private" nicht! dann funktioniert es (keine Fehlermeldung).

    Sobald ich initialisiere sourceList_(0) kommt die Fehlermeldung!

    Wenn sourceList_(0) nicht initialisiere ist, dafür aber der Quellcode mit sourceList drin bleibt, gibt es einen Speicherzugriffsfehler.



  • Das hoert sich so an als ob source_list irgendwo benutzt wird, wo erwartet wird, dass es auf ein gueltifes Objekt verweist. Ist es 0, dann gibts die Fehlermeldung, ist es nicht 0, wird dereferenziert und BUMM... Hats du evtl vergessen die Zugehoerige Ressource zu initialisieren bzw. sourceList darauf verweisen zu lassen?



  • sourceList_ verweist im Laufe des Programms auf ein weiteres EdgePtr Objekt. Das funktioniert aber!
    Das Problem muss doch schon vorher liegen?! Wenn alles (mit sourceList und was darauf referenziert oder auf das referenziert wird) auskommentiert ist entsteht schon der Speicherzugriffsfehler. Alleine durch das Initialisieren! ???



  • kann es mit abstracten klassen und "virtual" zutun haben?

    EdgeT ist nicht abstract (für sourceList_),
    CellT ist abstract (für cellList_)!
    HCellT ist eine abgeleitet Klasse...?



  • OKAY!

    Ich hatte ein Warning ignoriert. Dabei ging es um die Reihenfolge der Initialisierung. Auskommentieren bzw, Beachten der Reihenfolge hat das Problem gelöst.

    Danke für die Kommentare und den Beistand!
    Jo


Anmelden zum Antworten