4. SEGFAULT bei STL-Listenzugriff, uninitialisierte Liste

SEGFAULT bei STL-Listenzugriff, uninitialisierte Liste

  • S

    Hallo zusammen,

    ich bin auf ein seltsames Problem mit den Listen aus der STL gestoßen:

    In einer globalen Klasse ist eine void-Pointer Liste wie folgt deklariert:

    std::list<void *> m_list_Drivers;    // list of drivers

    So wie ich es verstehe, müsste die Liste beim Programmstart automatisch initialisiert wird. Wenn ich nun z.B. mit

    m_list_Drivers.push_back(foo_ptr);

    beendet sich das Programm mit einem SEGFAULT.
    Wenn ich mir die Liste im Debugger anschaue, sehe ich, dass die Listenpointer _M_next und _M_prev beide den Wert 0x0 haben ==> es muss krachen!

    Die Frage ist nun, warum sie Initialisierung nicht korrekt funktioniert?

    Es handelt sich bei meinem Projekt um ein Embedded-Projekt, das zuerst am PC entwickelt wurde (auf dem PC läuft's auch) und nun für einen ARM-Prozessor kompiliert werden soll.
    Da ich in sauberem ANSI-C++ programmiert habe, sollte es eigentlich kein Problem sein, wie gesagt, eigentlich 😞

    Arm-Konfiguration:
    ARM-Crosscompiler: gcc-4.1.1, glibc-2.5
    Prozessor: Atmel AT91RM9200
    Linux-Kernel: 2.6.18

    PC-Konfiguration:
    SusE 10.1
    GCC: 4.1.0

    Bin ziemlich ratlos, hatte jemand schon mal ein ähnliches Problem?

    Im Voraus schon mal Danke.

    Gruß
    Mathias

    0
  • C

    Setz doch mal einen Breakpoint in den Default-Ctor von list bzw. in die list::push_back() und schau dir an, wie die beiden Funktionen mit _M_prev und _M_next umgehen.

    PS: Tritt der Fehler direkt beim push_back() auf? Oder erst später? (und woher stammt der foo_ptr, den du da übergibst?)

    0
  • S

    Beim genaueren Einkreisen des Fehlers hat sich herausgestellt, dass das Problem gar nicht bei der Liste liegt, sondern allgemein beim Zugriff auf Membervariablen.
    Es sieht so aus, als ob die Membervariablen beim Erzeugen der Klasse beim Programmstart nicht korrekt initialisiert werden. Außerdem kann den Membervariablen nichts zugewiesen werden. Wenn ich z.B. einen Pointer auf int deklariere, und die Adresse eines anderen ints zuweise, steht in dem Pointer immer noch eine 0...

    Irgendetwas geht da gewaltig schief 😕

    0
  • C

    Zeig doch ganz einfach mal deine Klassendefinition und die Konstuktoren der Klasse.

    (und wo wir gereade dabei sind - wie und wo wird dein Objekt angelegt?)

    0
  • S

    Hier einmal die verkürzte Klassendefinition:

    class CFoo
{

  // Construction / Destruction code
  public:
    CFoo();	
    virtual ~CFoo();	

  protected:
    std::list<void *> foo_list;
    int abc;
}

    Erzeugen des Objekts in einer anderen C++ Datei (global):

    CFoo oFoo;           // global object

    In allen C++ Dateien, in denen das globale Objekt verwendet wird, wird es mit

    extern CFoo oFoo;    // external object

    eingebunden.

    Beispielkonstruktor zum Testen:

    CFoo::CFoo()
{
  abc = 123;
  cout << abc << endl;
  // Ausgabe: 0
}

    Wie man sieht ist es eigentlich ziemlich simpler Code...

    Und wie gesagt, auf dem PC läuft alles, aber das kann ja auch Zufall sein, v.a. bei Pointer-Problemen und ähnlichem.

    0
  • S

    Fehler gefunden 😃

    Das Problem war, dass ich, weil einige Strukturen über Pipes verschickt werden, generell alle Strukturen (also auch alle Klassen???) mit "#pragma packed(1)" gepackt habe. Das scheint den ARM-Compiler in Kombination mit den Libraries (bei denen vermutlich nichts gepackt ist) total verwirrt zu haben. Seltsam bleibt aber weiterhin, dass es auf dem PC trotzdem funktioniert hat...
    Jetzt habe ich wirklich nur die Strukturen, bei denen es nötig ist mit __attribute__((pack)) gepackt und voila, es funktioniert!

    Danke CStoll für Deine Bemühungen!

    Gruß
    Schneider-Hütter

    0
Anmelden zum Antworten