Exception bei Übergabe von Vectoren an rekursive Funktion



  • Hallo,

    Ich habe eine Funtion

    void foo( vector<blub*>&bvec1, vector<blab*>& vec2, vector<blob*>& vec3)
    

    In dieser Funktion lösche Ich ein oder mehrere Elemnte von bvec2 und füge Elemente zu vec3 hinzu.

    Am Ende ruft sich die Funktion selbst wieder auf, rekursion eben.

    Beim Debuggen bin ich die Funtion durchgegangen und bei

    return foo(vec1, vec2, vec3)
    

    Erhalte ich eine Exception:

    An unhandled exception of type 'System.Runtime.InteropServices.SEHException' occurred in foo.exe
    
    Additional information: External component has thrown an exception.
    

    Diese Exceoption tritt beim übergeben auf da ich mit dem Debugger gar nicht erst wieder in die rekursiv aufgerufene Funtion komme.

    Leider bin ich mit meinem Latein am ende.
    Hat jemmand eine Idee?

    gruss
    deb



  • HI, mehr Code wäre hilfreich...
    Meinst du nicht STL-Algorithmen könnten deine Funktion ersetzten ?



  • eine SEH exception deutet darauf hin dass du dir irgendwo den speicher zerschossen hast. du hantierst ja auch mit zeigern rum... ueberpruefe das mal genauer... du loescht sachen - also schau nach ob du schoen brav das richtige loeschst und alle deine zeiger auch gueltig bleiben, etc...



  • @FreakCoder:
    Ich glaube nicht das die stl ein system von ungleichungen ordnen kann:)

    @Shade Of Mine

    Also das löschen:

    vector<blub*>::iterator it = vecblub.begin();
    
    while(it != vecblub.end())
    {	
    	if( (**it).value ==  5){
    		delete (*it);
    		it = Inequations.erase(it);
    	}
    	else
    		++it;
    }
    

    Ich hatte erst kein delete aber auch wenn ich ein delete dabei habe hängt es sich auf.

    gruss
    deb



  • Hi,

    nicht, dass ich wirklich helfe könnte, aber

    deb schrieb:

    ...'System.Runtime.InteropServices.SEHException'...
    

    mich erinnert diese Benamsung eigentlich eher an Java denn an C++.
    Kann es sein, dass Du irgendein Framework verwendest, dass sich hier beklagt ?

    Gruß,

    Simon2.



  • System.Runtime.InteropServices.SEHException ist .Net. Das tut aber nichts zur Sache, da dort der C++ Code auch gültig ist. Insofern also kein Problem.



  • Und übrigens: System.Runtime.InteropServices.SEHException kapselt eine SEHException aus dem nativen Code, damit sie managed (z.B. von C#) abgefangen werden kann. Sie tritt hier auf, weil sie auf die oberste Ebene kocht und dann in main (welches mindestens managed/unmanaged gemischst ist) die Ausführung abbricht. Wenn du nun einen Stack-Trace sehen willst, fange die Exception und gib sie via Console::Write aus.



  • deb der code ist korrekt. lass dir wirklich mal nen trace ausgeben, dann siehst du in welcher zeile der fehler fliegt.
    du sagst ja auch dass du etwas rekursiv machst, dann kann man auch mal leicht nen zeiger fehler machen...

    vielleicht schmiert ja auch das delete ab, weil der zeiger ungueltig ist.

    debugger und/oder stacktrace verraten dir mehr.



  • Was meinst du mit stacktrace?Leider habe ich noch nie was davon gehört.
    Ich bin bisher eben immer schrittweise meinen Code durchgegangen und hab geschaut wie sich die variablen veränderen.

    Das Probelm ist das der Exception geworfen wird beim return der funktion.
    also bei

    return foo(veca, vecb, vecc);
    

    mh eigentlich kann an den 3 vektoren nichts faul sein... es sind jeweils referenzen auf vector<bla*>* und den speicher habe ich mit new reserviert.

    so long
    deb



  • deb schrieb:

    Was meinst du mit stacktrace?Leider habe ich noch nie was davon gehört.

    fang die exception die fliegt mal selber ab, mit try/catch

    und die Exception die du dann faengst hat ein property "StackTrace".
    Das liefert dir nen string der dir zeigt wo was alles aufgerufen wurde. und auch wo die exception geflogen ist.

    mh eigentlich kann an den 3 vektoren nichts faul sein... es sind jeweils referenzen auf vector<bla*>* und den speicher habe ich mit new reserviert.

    bei zeigern kann immer irgendwas faul sein 😉

    wirf deinen debugger an und schau wo der fehler genau ist...



  • Hi ich konnte das Problem jetzt lösen hatte dummes zueg mit einem pointer gemacht.

    Nur habe ich jetzt schon wieder ein Problem:

    Beim hinzufügen zu einem vektor erhalte ich:
    "vector subscript out of range"

    das komische ist das es erst aufgetretten ist nachdem ich mehr als 4 elemente dem vektor hinzugefügt habe. wenn ich die zusätzlichen wiederauskommentiere erhalte ich den Fehler immernoch.

    Der code:

    class Inequation
    {
    	public:
    
    	Inequation(unsigned int Smaller,unsigned int Higher	)
    		: smaller(Smaller),higher(Higher)	
    	{
    	}	
    
    	unsigned int smaller;	
    	unsigned int higher;	
    };	
    
    ...
    	vector<Inequation*>* Inequations = new vector<Inequation*>;
        Inequations->push_back(new Inequation(7, 8));
    

    Das Problem ist mir leider völlig schleierhaft?



  • Sorry mein letzter Beitrag stimmt nicht, der fehler ereignet sich beim übergeben in eine Funtion.
    Ich erstelle 3 ähnliche vektoren nur mit anderen elementen und nur bei einem erhalte ich die Fehlermeldung?



  • Nachtrag:

    Bei

    Inequations->push_back(new Inequation(7, 8));
    

    hängt sich mein Programm auf.

    Bei

    Inequations->push_back(new Inequation(7, 7));
    

    hängt sich das Programm nicht auf.

    Der Error kommt aus folgender stl funktion

    reference operator[](size_type _Pos)
    		{	// subscript mutable sequence
    
     #if _HAS_ITERATOR_DEBUGGING
    		if (size() <= _Pos)
    			{
    			_DEBUG_ERROR("vector subscript out of range");
    			_SCL_SECURE_OUT_OF_RANGE;
    			}
     #endif /* _HAS_ITERATOR_DEBUGGING */
    		_SCL_SECURE_VALIDATE_RANGE(_Pos < size());
    
    		return (*(_Myfirst + _Pos));
    		}
    

    Ich hab die Funtion mal gedebuggt und wenn sich mein Programm aufhängt dann ist _Pos = 8 ? Kann das ein Zufall sein? Kann der stl beim verwalten der Klasse ein Fehler unterlaufen sein und es wurde in einen falschen speicherbereich geschrieben der eigentlich _Pos ist?

    so long
    deb


Anmelden zum Antworten