[algorithm][string] trim fails on VC8 with _HAS_ITERATOR_DEBUGGING=0

Platform - VC 8.0 with Boost 1.33.1 On a recent project, we started defining _HAS_ITERATOR_DEBUGGING=0 for our debug builds. We were using maps & hash_maps with 100,000+ elements, and debugging was unbearably slow. We were mostly successful, but ran across some strange behavior with Boost's trim function. The follow recreates the situation we saw in our larger program. The completely weird thing (anyone from Microsoft read this?) is that we get a runtime assert for a corrupted iterator, even though we've turned off iterator debugging... This program runs to completion if _HAS_ITERATOR_DEBUGGING is set to 1, and fails if it is set to 0. trim() fails reliably on strings created using the template<IteratorT> basic_string(iterator,iterator) constructor. Any insight, workarounds, or any experience at all with _HAS_ITERATOR_DEBUGGING would be greatly appreciated. Dave Moore #define _HAS_ITERATOR_DEBUGGING 0 #include <iostream> #include <string> #include <boost/algorithm/string/trim.hpp> using namespace std; int main(int argc, char* argv[]) { const char *p="te"; size_t sz=2; string s1(p,sz); boost::algorithm::trim(s1); // works const char *p1=p+1; string s(p,p1); // fails if _HAS_ITERATOR_DEBUGGING=0 boost::algorithm::trim(s); return 0; } Backtrace at time of assertion. Sorry for lack of readability. msvcp80d.dll!std::_Debug_message() + 0x21 bytes msvcp80d.dll!std::_Iterator_base::_Orphan_me() + 0x5e bytes msvcp80d.dll!std::_Iterator_base::~_Iterator_base() + 0x41 bytes msvcp80d.dll!std::_Ranit_base<char,int,char const *,char const &,std::_Iterator_base>::~_Ranit_base<char,int,char const *,char const &,std::_Iterator_base>() + 0xf bytes msvcp80d.dll!std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>
::~_String_const_iterator<char,std::char_traits<char>,std::allocator<char> () + 0xf bytes msvcp80d.dll!std::_String_iterator<char,std::char_traits<char>,std::allocator<char> ::~_String_iterator<char,std::char_traits<char>,std::allocator<char> () + 0xf bytes msvcp80d.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char> ::erase() + 0x120 bytes algotest.exe!boost::algorithm::trim_right_if<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,boost::algorithm::detail::is_classifiedF>(std::basic_string<char,std::char_traits<char>,std::allocator<char> > & Input="t", boost::algorithm::detail::is_classifiedF IsSpace={...}) Line 235 + 0xe2 bytes C++ algotest.exe!boost::algorithm::trim_if<std::basic_string<char,std::char_traits<char>,std::allocator<char> ,boost::algorithm::detail::is_classifiedF>(std::basic_string<char,std::char_traits<char>,std::allocator<char> & Input="t", boost::algorithm::detail::is_classifiedF IsSpace={...}) Line 351 + 0x23 bytes C++ algotest.exe!boost::algorithm::trim<std::basic_string<char,std::char_traits<char>,std::allocator<char>
(std::basic_string<char,std::char_traits<char>,std::allocator<char> & Input="t", const std::locale & Loc={...}) Line 368 + 0x27 bytes C++ algotest.exe!main(int argc=1, char * * argv=0x00355c30) Line 20 + 0x3b bytes C++ algotest.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C algotest.exe!mainCRTStartup() Line 403 C KERNEL32.DLL!_BaseProcessStart@4() + 0x23 bytes

On 2/23/06, Dave Moore <jdmoore99@gmail.com> wrote:
This program runs to completion if _HAS_ITERATOR_DEBUGGING is set to 1, and fails if it is set to 0. trim() fails reliably on strings created using the template<IteratorT> basic_string(iterator,iterator) constructor.
Any insight, workarounds, or any experience at all with _HAS_ITERATOR_DEBUGGING would be greatly appreciated.
I have had a similar problem. It turns out you can't turn off iterator debugging without recompiling the C++ libs. The C++-libs are all compiled with iterator debugging on. -- /Johan.
participants (2)
-
Dave Moore
-
Johan Lindvall