Infinite loop with STL erase and remove_if when using VS 2010 and Parallel Composer 2011

[neilhenderson]

Environment:

• Windows 7 Ultimate 64-bit
• Visual Studio 2010
• Parallel Studio 2011
• Building Win32|Debug project configuration

The following code produces an infinite loop:

[cpp]int compare = 5;
std::vector ints;

ints.erase( std::remove_if(ints.begin(), ints.end(), [compare](int i)->bool
{
	return i > compare;
}), ints.end() );[/cpp]

The infinite loop is in xutility, std::_Iterator_base12::_Orphan_me().

The problem occurs regardless of whether the vector contains any elements.

The problem does not occur if the lambda does not capture the 'compare' variable, or if you split the erase and remove_if into separate statements. E.g. the following works fine:

[cpp]std::vector::iterator it = std::remove_if(ints.begin(), ints.end(), [compare](int i)->bool
{
	return i > compare;
});

ints.erase(it, ints.end());[/cpp]

[JenniferJ]

It seems to me that this is more an user error than compiler bug.

In the lambda code sample the 2nd parameter of "ins.erase()" is depending on the 1st parameter. It is not a good idea to do so because the compiler could evaluate the parameters in any order.

Jennifer

[neilhenderson]

Hi,

Thanks for your reply. However, I don't think the order of parameter evaluation matters here.

std::remove and std::remove_if do not invalidate or change the container's begin() or end() iterators. They just change the order of elements inside the container, and then return an iterator to the new end of the range.

So it doesn't matter which of the erase() parameters is evaluated first, because the container's end iterator does not change.

I still believe this is a bug and is related to the lambda capture of the local 'compare' variable.

Thanks,

Neil

[JenniferJ]

Yeh, you're right. the remove_if doesn't change the int.end().

I got a testcase, but it works for me with the Intel Parallel Composer 2011. Please try it on your system and see if it works. It might be the test is too simple.

Thanks,
Jennifer

[neilhenderson]

Hi,

I still get the same problem with the test case you uploaded. Here are the exact steps I perform:

1. Start VS 2010 and create a new Win32 Console Application

2. Use the default options (yes for precompiled headers)

3. Paste your test case code over the code in the CPP file, but leaving the #include "stdafx.h" at the top.

4. Convert the project to Intel C++

5. Build the solution (Debug|Win32)

6. Start debugging (F5 key).

Program hangs. When I force a break, the infinite loop is in the aforementioned location.

I've also tried disabling precompiled headers and a non-Unicode project with the same result.

Thanks,

Neil

[JenniferJ]

I used a command line build environment for the testing. I did it again, it saw the problem this time with /Od /MDd. It's ok with /Od only.

So one of the debug lib has a bug. Thanks for verifying. I'll send it to the compiler engineering team.

The only work-around is to use "/Od /MD".

Thanks again,
Jennifer

[Neil_Henderson]

Great, thanks for letting me know.

Neil

[Alexander_W_Intel]

Hi Neil,

the issue is finally fixed in the Parallel Composer 2011. I've tested it with the actual Update 4 and couldnt reproduce the bug anymore.

Thanks again for submitting!
Alexander