Visual C++ 2010 std::set find broken

Question

I'm changing over from Visual Studio 2008 -> 2010 and I've come across a weird bug in my code when evaluating a find on a std::set of pointers.

I know that this version brings about a change where set::iterator has the same type as set::const_iterator to bring about some compatability with the standard. But I can't figure out why this section of code which previously worked now causes a crash?

void checkStop(Stop* stop)
{
    set<Stop*>                      m_mustFindStops;
    if (m_mustFindStops.find(stop) != m_mustFindStops.end()) // this line crashes for some reason??
    {
         // do some stuff
    }
}

PS m_mustFindStops is empty when it crashes.

EDIT: Thanks for the quick replies... I can't get it to reproduce with a simple case either - it's probably not a problem with the set its self. I think that heap corruption may be a culprit - I just wish I knew why changing compilers would suddenly cause corruption for the same code and same input data.

I can't reproduce the error. This suggests that something else is going wrong. The smallest compilable example that reproduces the error and that we can run would be perfect. — Martin York, Nov 24 '10 at 03:28
I'm continuously amazed by people who, upon discovering a problem, assume that the bug is in MSVC (which has been tested to high heaven and beyond by millions of people around the planet) rather than their own code (which has been tested by one person, if at all). Not having a go at you @Jamie (and it's really just to do with your title - the text itself indicates you may think the bug is yours), I just find it interesting. Maybe you should do a web search for "cognitive dissonance" - "shooting yourself in the foot, then blaming the gun" was the best explanation I ever heard on that :-) — paxdiablo, Nov 24 '10 at 03:32
I didn't say there was a problem in MSVC, just that I knew it had changed and that perhaps I hadn't fully understood the change. — Jamie Cook, Nov 24 '10 at 03:39
@Jamie: but your title says `std::set` is broken, which it isn't ;) — jalf, Nov 24 '10 at 05:46
A new compiler means a new heap manager in the C runtime libraries. No big surprise that this could change behaviour of the code. The first thing I would do is run the Debug build of this code in the Visual Studio debugger. — Steve Townsend, Nov 24 '10 at 11:51
@Jamie - there is advice here on how to try to track heap problems down. First thing to try would be to run the Debug build inside the debugger. Often a lot of help there. http://stackoverflow.com/questions/1069/heap-corruption-under-win32-how-to-locate — Steve Townsend, Nov 24 '10 at 19:51

score 1 · Accepted Answer · answered Nov 24 '10 at 03:28

1

The only thing I can think of is that you have multiple threads, and m_mustfindStops is in fact a member or global variable and not a local to this function. There is no way the code above can cause problems, if correct and taken in isolation.

If you have multiple threads, then read access concurrent with write access will cause random errors - even if the container looks empty, it might not have been when the find call started.

Another possibility is that some other code has corrupted the heap, in which case however any of your code that uses heap memory could malfunction. With that in mind, if it's always this logic that breaks, my bet would be on a threading issue.

btw - there is absolutely nothing wrong with std::set in Visual C++ v10 - your code must have a bug.

answered Nov 24 '10 at 03:28

Steve Townsend

53,498
9
91
140

Parts of the application are multithreaded but the section in question is not. Any thoughts on how to track down the corruption culprit? – Jamie Cook Nov 24 '10 at 03:40
@Jamie: What warning level is the compiler set at? Does it compile with no warnings? Did you use smart pointers rather than raw pointers. Did you use at() instead of operator[]? Have you use a product to test your heap boundaries (like valgrind). – Martin York Nov 24 '10 at 03:47
It is set to level 3 with warnings treated as errors. Using smart pointers in general and our policy is to use .at() for vectors. Haven't used valgrind previously... will have to start me thinks – Jamie Cook Nov 24 '10 at 05:02
1

@Jamie: valgrind cannot be used on Windows as far as I know, hope you have a Linux box handy. – Matthieu M. Nov 24 '10 at 07:22
ah yes... well that won't be happening then - app is most definitely windows only. Thanks anyways – Jamie Cook Nov 25 '10 at 05:19

Visual C++ 2010 std::set find broken

1 Answers1