incompatible iterators

C++ coding using Panda3D
1

The line

while ( ei != _edges.end() && not_any )

in EggMesherStrip::cut_sheet() causes an assertion failure in Visual Studio 2010. The mate_pieces call invalidates the iterator somehow. The workaround is to do

while ( not_any && ei != _edges.end() )

instead.

2

Ah, very nice! Thanks!

David

3

Can also confirm this happens in VS2008, and the fix is the same, but I also need to similarly change the while condition three lines down from:

while (si != strips.end() && not_any)

to

while (not_any && si != strips.end())

You’ve probably already done this in the svn, which I have not pulled from.

Looking at the mate_pieces function, it’s removing items, which is wrecking the iterators. Short of returning a status flag that forces a restart or resync of the iterator, not sure how to resolve that.

4

I just made the second suggested change.

But these are STL lists, not vectors. While a vector has the property that removing an item will invalidate all of the existing iterators, a list does not share this property. Removing items from a list should invalidate only iterators referencing the removed items.

David

5

Dug further into this just because it was bugging me. Where the error occurs is actually deeper down than I first thought, and is in EggMesherStrip::combine_edges, at the very end where it removes the “to-be-junked edges”. The edges being removed are the owners of the _strips member item (the 2nd while loop mentioned above). In other words, combine_edges is deleting the list out from under the strips iterator. This does not invalidate the iterator, but leaves it as-is, referencing something that no longer exists.

The fix - where the not_any flag is checked before the iterator comparison - works because it short-circuits the rest of the if. Why it doesn’t fail in release build is because of either (a) the optimizer is shuffling the order around for best performance (and we get lucky because of this) or (b) since the check is debug-only, the comparison doesn’t validate the iterator, which is left pointing to now-unused memory (and it’s a small miracle that this doesn’t cause other problems) so it always appears to be “not the same”.

Not all models will cause this problem; I used world.egg for my testing.

6

Ah, that makes perfect sense! Thank you for researching this.

David