- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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::vectorints; 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]
Link Copied
7 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Great, thanks for letting me know.
Neil
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page