From an earlier email about this bug:

It bombed on the min_it++, which was odd.

Looking at the loop, I suspect what happens is this:

• Erases the last item in the 'min' list, setting min_it to min.end(),
• Attempts to increment min_it (which isn't valid on the end iterator)

The patch at the bottom of this mail avoids the crash, but DOES NOT fix the root bug. The root bug is a bit more insidous (imagine that, MSVC helped us catch a real bug!). Consider the following test case:

– BEGIN – #include <iostream> #include <list>

int main() { std::list<int> ilist; for (int i = 1; i < 10; i++) { ilist.push_back(i); }

 for (std::list<int>::iterator l_it = ilist.begin();
      l_it != ilist.end();
      l_it++)
 {
     std::cout << *l_it << " ";
     if (*l_it == 4)
         l_it = ilist.erase(l_it);
 }
 std::cout << std::endl;

 return 0;

} – EOF –

Here's the output:

$ ./test 1 2 3 4 6 7 8 9

Note that it skipped over '5'. The reason is because the iterator ends up being incremented twice (the erase() moves the iterator one forward of the previous position). So the obvious solution might be to decrement the iterator immediately after erase(), right? Wrong. If you erased the last element in the list, your iterator will be == list.end(), which is an iterator you should NEVER use ++ or – on.

Signed-off-by: Steven Noonan <steven@uplinklabs.net>