Seltsamer Crash, std::vector push_back



  • Icematix schrieb:

    Wozu einen virtuellen Destruktor?

    Les' mal das hier.


  • Mod

    Icematix schrieb:

    Außerdem tritt das Problem ja nicht beim Löschen der Objekte sondern beim Anlegen auf.

    Vielleicht, aber das ist der Fehler, der mir aufgefallen ist. Abgesehen davon, hast du nicht ausdrücklich gesagt, dass es schon beim allerersten push_back knallt.
    Nebenbei scheint mir

    void addState(State* state)
            {
                stateList_.push_back(state);
                std::sort(stateList_.begin(), stateList_.end(), compareStates);
            }
    

    nicht besonders effizient zu sein, wenn - wie ich annehme - sich der Wert von getPriority wärend der Lebenszeit eines State-Objektes nict ändert, stateList_ also immer sortiert ist. Dann ist es besser, gleich die richtige Einfügestelle zu ermitteln und nicht ein komplettes sort auf den vector loszulassen

    void addState(State* state)
            {
                stateList_.insert( std::lower_bound( stateList_.begin(), stateList_.end(), state, compareStates), state );
            }
    


  • Eingefügt, geholfen hat es leider nix 😕

    Edit: @Camper: Ja, stimmt. Nur hab ich mir darüber keine Gedanken gemacht, bei sagen wir mal ~20 States ist die Rechenzeit echt vernachlässigbar. Aber gute Idee, ich ändere es gleich mal.



  • Vielleicht solltest Du mal überprüfen, was vorher so passiert. In Deinen von State abgeleiteten Objekten z.B.
    Beim push_back wird ja nur ein Pointer eingefügt. Dabei kann eigentlich nichts schief gehen. Ich schätze mal, dass Du Dir vorher irgendwo den Stack zerballerst (also nicht im gwposteten Code).



  • Tachyon schrieb:

    Vielleicht solltest Du mal überprüfen, was vorher so passiert. In Deinen von State abgeleiteten Objekten z.B.
    Beim push_back wird ja nur ein Pointer eingefügt. Dabei kann eigentlich nichts schief gehen. Ich schätze mal, dass Du Dir vorher irgendwo den Stack zerballerst (also nicht im gwposteten Code).

    Stack zerballern? Klingt abenteuerlich.
    Außerdem ist es ohne dem Funktionsaufruf absolut stabil...



  • Icematix schrieb:

    Außerdem ist es ohne dem Funktionsaufruf absolut stabil...

    Diese Aussage muss nicht stimmen. Das ist ja das furchtbare, wenn du undefiniertes Verhalten erzeugst. Es kann sehr lange gut gehen, bis du auf einmal etwas völlig harmloses (wie ein push_back) machst und dann gehts nicht mehr und du kriegst einen merkwürdigen Fehler, wie den hier.

    Ich würde auch darauf tippen, dass du irgendwo anderst etwas falsch machst. (Zugriff auf freigegebenen Speicher z.B?)



  • Habe das Problem eingegrenzt.
    Könnte es daran liegen, dass mein FiniteStateMachine-Objekt ein statisches Objekt ist und ich addState im (natürlich nicht-statischen) Konstruktor aufrufe?

    Hier mal eine grobe Übersicht der Klasse, in welcher ich es nutze (Ist ne Singleton) :

    Klasse:

    class Foobar
    	{
    	public:
    
    		...
    
    		static Foobar*		getInstance();
    		static void		destroyInstance();
    
    		....
    
    	private:
    
    		.....
    
    		//FSM
    		static Navigator::FiniteStateMachine fsm;
    
    		//Pointer to the instance
    		static Foobar* instance;
    
    		Foobar();
    		~Foobar();
    
    		....
    	};
    

    Konstruktor:

    Foobar::Foobar()
    	{
    		...
    
    		//Set up the FSM
    		fsm.addState(new IdleState);
    
    		...
    	}
    

    Wenn ich ein neues FiniteStateMachine-Objekt im Konstruktor erstelle und diesem States hinzufüge, crashed es nicht.

    Mache ich was ganz offensichtlich falsch?



  • Sorry für den Doppelpost.
    Hab die FSM jetzt zeitweise nicht-static gemacht (musste sämtlich Aufrufe in statischen Funktionen herauskommentieren) und es gibt keinen Crash mehr !

    Wo könnte das Problem sein, bin mit meinem Latein am Ende. Benutze statische Objekte anderer Klassen auf die selbe Art und es gab nie Probleme 😕



  • Könnte es daran liegen, dass mein FiniteStateMachine-Objekt ein statisches Objekt ist und ich addState im (natürlich nicht-statischen) Konstruktor aufrufe?

    So weit ich das verstehe, ist das völlig unbenklich...

    und es gibt keinen Crash mehr

    denk immer daran: undefiniert bleibt undefiniert...
    Das Problem kann wo ganz anders liegen! Das ist eben die sch**** an undefiniertem Verhalten - man kann im Grunde genommen noch mal nen neues Projekt anfangen, wenn man nicht weiß, wo man es fabriziert hat...

    bb



  • unskilled schrieb:

    man kann im Grunde genommen noch mal nen neues Projekt anfangen, wenn man nicht weiß, wo man es fabriziert hat...

    Oder ein paar Nächte lang debuggen. Wenn man den Fehler dann hat und merkt, wie dämlich der war, dann ist das der Moment, wo man begreift, wie wichtig es ist definiertes Verhalten zu haben und alles undefinierte einfach mal misstrauisch anzuschauen.



  • Naja, habe absolut keine Lust mehr auf den Scheiß und habe mich zu einer Alternativlösung entschieden:

    Da ich sowieso große Teile des Programm scriptbar machen möchte, wird jetzt auch das auf Scripts umgewälzt.
    Wird zwar zwangsläufig darauf hinauslaufen dass nur das Allernötigste in C++ geschrieben wird (Low-Level Hooks etc), aber ich denke Performancemäßig wird Python schon ok sein. 😉


Anmelden zum Antworten