Probleme mit STL-Vector von Microsoft



  • Es tauchen zwar auch eher selten mal Bugs in der STL auf, welche M$ nutzt, aber der std::vector funktioniert 😃 Wie gesagt, debugge das ganze mal wie von mir beschrieben.



  • Pellaeon schrieb:

    Wahrscheinlich greifst du an irgendeiner Stelle über den maximalen Feldindex hinaus zu. Im Debug-Mode fliegt dann halt der Assert. WEnn die Assertion kommt, klicke auf wiederholen und dann abbrechen. So springt der Debugger dann an die Stelle der Assertion. Das wird dann irgendwo im STL-Code sein. Über die Funktionsaufrufliste kannst du die darüber liegenden Funktionen anschauen und so suchen, an welcher Stelle dein eigener Code den falschen Zugriff macht.

    Genau das habe ich gemacht. Ich versucht nochmal etwas sinnvollen Code zu Posten.

    while (!m_v_PointChangesFromUIQueue.empty()) {
    		changePoint changeCp = m_v_PointChangesFromUIQueue.back();
    		changePoint toChange = m_v_intern_changeList[changeCp.getIndex()];
    		assert(toChange.getIndex() == changeCp.getIndex());
    // tue was...
    		m_v_PointChangesFromUIQueue.pop_back();
    	}
    

    Die Listen m_v_PointChangesFromUIQueue und m_v_intern_changeList sind STL Vektoren. changePoint ist ein Vec3f mit einem zusätzlichen Indexfeld. Dieses Indexfeld gibt den Platz in der m_v_intern_changeList an. Wenn ich also auf das n-te Element der m_v_intern_changeList zugreife, so sollte der changePoint auch den Index n besitzen. Dies läuft auch unter Linux. Nun könnte ich mir vorstellen das der Linuxprogrammierer bei uns, die GNU STL bis in die letzten Feinheiten ausgenutzt hat und ein nicht Standardverhalten bei den Zugriffen ausnutzt. Aber vielleicht ist es auch anders rum und die MS STL hat ein nicht Standardverhalten bei den zugriffen und deshalb läuft mein Code ins assert.

    Wenn mir jetzt natürlich alle beteuern das die GNU STL und die MS STL in allen belangen gleich reagieren, müsste ich an einem anderen Punkt weitersuchen. Nur wollte ich diesen Aspekt erstmal ausschließen. Es treten nämlich noch an diversen anderen Stellen Ungereimheiten auf.

    Grüße, sjoe.



  • Pellaeon schrieb:

    Es tauchen zwar auch eher selten mal Bugs in der STL auf, welche M$ nutzt, aber der std::vector funktioniert 😃

    Na das ist ja schön zu hören. Ich werde mir mal anschauen wie die Vectoren befüllt werden.



  • m_v_intern_changeList[changeCp.getIndex()];
    guck mal genau durch, was in der zeile passiert... ich vermute mal, dass hier schon was schief geht...

    aber allg. finde ich dieses stück code nicht gerade logisch...

    bb

    PS: Die assertion scheint mir nicht gerade ein logik-fehler zu sein...



  • Spricht dein assert an, oder einer vom std::vector?

    Ja, aber das lustige ist doch, das der Code unter Linux wunderbar läuft, aber unter Windows stürzt er ab.

    Nur weil etwas kein assert auslöst und nicht abstürzt, heisst das nicht, dass es korrekt ist. Die asserts in von MS verwendeten Standard Library zeigen Dir einfach dass dein Code falsch ist.

    @Pellaeon

    Wahrscheinlich greifst du an irgendeiner Stelle über den maximalen Feldindex hinaus zu.

    Ist aber nicht der einzige Grund. Kann auch sein, dass iteratoren von verschiedenen Container Instanzen genutzt werden, oder iteratoren die nicht mehr gültig sind.

    Simon



  • theta schrieb:

    Spricht dein assert an, oder einer vom std::vector?

    Mein assert spricht an. Also der Index unterscheidet sich.



  • sjoe schrieb:

    Mein assert spricht an. Also der Index unterscheidet sich.

    Und nichtmal der Index im vector, sonder der Index den du irgendwann mal reingeschrieben hast. Als erstes würde ich da auf einen Fehler bei der Befüllung der vectoren oder beim Index-setzen schließen. Da gleich von einem Fehler in einer der meistbenutzten C++-Bibliotheken dies gibt auszugehen halte ich für extrem gewagt 😉



  • Da gleich von einem Fehler in einer der meistbenutzten C++-Bibliotheken dies gibt auszugehen halte ich für extrem gewagt 😉

    Von einem Fehler ging ich ja nicht aus, ich dachte ehr an Implementierungsunterschiede. Sowas was im Standard nicht festgelegt ist.

    Ich habe inzwischen ein Workaround entwickelt.

    Mich würde trotzdem mal interessieren ob es Geschwindigkeitsunterschiede zwischen den STLs gibt. Ich habe mal gelesen das von der STL von VS 2003 abgeraten wurde. Ist das immer noch aktuell?

    Grüße, sjoe.



  • kommt darauf an. für normale projekte tut sie es.

    sobald du aber z.b. über DLL grenzen hinweg auf den vector zugreifen (auch schon
    lesend) willst, kommt es zu mysteriösen abstürzen (eigene erfahrung :().

    und das liegt daran, dass die ms-stl wirklich kaputt war.

    je nachdem wie dein projekt aussieht kann es wirklich daran liegen.
    in den express-versionen (08) sollte das behoben sein.



  • sjoe schrieb:

    Ja, aber das lustige ist doch, das der Code unter Linux wunderbar läuft, aber unter Windows stürzt er ab.

    Das sollte dich aber eher zum Schluss führen, dass die Microsoft STL diesbezüglich besser ist, weil sie mehr Fehler anzeigt (man sollte nicht als erstes von einem Bug in der Standardbibliothek ausgehen). Ich denke, die GNU STL ist da vielleicht weniger strikt und lässt gewisse Dinge durchgehen. Dass da ein paar Sachen mehr "funktionieren", liegt sehrwahrscheinlich am undefinierten Verhalten.



  • Das sollte dich aber eher zum Schluss führen, dass die Microsoft STL diesbezüglich besser ist, weil sie mehr Fehler anzeigt (man sollte nicht als erstes von einem Bug in der Standardbibliothek ausgehen). Ich denke, die GNU STL ist da vielleicht weniger strikt und lässt gewisse Dinge durchgehen. Dass da ein paar Sachen mehr "funktionieren", liegt sehrwahrscheinlich am undefinierten Verhalten.

    das wiederum halte ich fuer eine gewagte These 🙂

    Ich hab mir im Allgemeinen angewoehnt Fehler immer zuerst in meinem Code zu suchen und zwar bei der Verwendung jeglichem nicht von mir geschribenen Code. in einem Grossteil der Faelle liege ich damit richtig.

    Kann aber auch an mir liegen 😃



  • TheBigW schrieb:

    Ich hab mir im Allgemeinen angewoehnt Fehler immer zuerst in meinem Code zu suchen und zwar bei der Verwendung jeglichem nicht von mir geschribenen Code. in einem Grossteil der Faelle liege ich damit richtig.

    Bei Code von Arbeitskollegen oder eher neueren bzw. nicht ausführlich getesteten Frameworks, ja. Bei Problemen mit der STL würde ich den Fehler allerdings nicht als erstes in der Standardbibliothek selbst suchen. Gerade weil die Microsoft-Assertions sehr genau angeben, wo ein Fehler aufgetreten ist, und man so mit grosser Wahrscheinlichkeit den Fehler bei sich findet (wenn man sich ein wenig auskennt). Ich zumindest habe noch nie einen Bug in der Standardbibliothek entdeckt. Designfehler schon, aber das liegt nicht an der Implementierung.

    Abgesehen davon erinnert "das lustige ist doch, das der Code unter Linux wunderbar läuft, aber unter Windows stürzt er ab" ein wenig an einen typischen Bash und die fehlende Bereitschaft, eigene Fehler zuzugeben. 😉


Anmelden zum Antworten