Hello, the following test program segfaults when _GLIBCXX_DEBUG was defined at compile time. People in #boost@freenode claimed this was rather be a gcc bug, so I post it here: ======= #include <boost/regex.hpp> int main() { std::string s("table.dat"); boost::regex expression("table.dat"); boost::regex_match(s, expression); return 0; } // try to compile it with and without the _GLIBCXX_DEBUG macro defined // // works OK: g++ -Wall -pedantic -g -lboost_regex -o test test.cc // segfaults:g++ -Wall -pedantic -g -lboost_regex -D _GLIBCXX_DEBUG -o test test.cc ======= A backtrace: ======= src/test> gdb ./test GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-suse-linux"...Using host libthread_db library "/lib64/libthread_db.so.1". (gdb) run Starting program: /home/dhornun/diplom/sphere_packing/version3/src/test/test warning: Lowest section in /usr/lib64/libicudata.so.34 is .hash at 00000000000000e8 [Thread debugging using libthread_db enabled] [New Thread 47694321665408 (LWP 6180)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47694321665408 (LWP 6180)] 0x00002b60b1c940cd in __gnu_debug::_Safe_iterator_base::_M_detach () from /usr/lib64/libstdc++.so.6 (gdb) bt #0 0x00002b60b1c940cd in __gnu_debug::_Safe_iterator_base::_M_detach () from /usr/lib64/libstdc++.so.6 #1 0x00002b60b1c94176 in __gnu_debug::_Safe_iterator_base::_M_attach () from /usr/lib64/libstdc++.so.6 #2 0x00002b60b1c942f3 in __gnu_debug::_Safe_sequence_base::_M_detach_all () from /usr/lib64/libstdc++.so.6 #3 0x0000000000403317 in ~_Safe_sequence_base (this=0x7ffff9135968) at /usr/include/c++/4.1.0/debug/safe_base.h:170 #4 0x000000000040332f in ~_Safe_sequence (this=0x7ffff9135968) at /usr/include/c++/4.1.0/debug/safe_sequence.h:99 #5 0x0000000000403350 in ~vector (this=0x7ffff9135950) at /usr/include/c++/4.1.0/debug/vector:95 #6 0x00000000004033df in ~match_results (this=0x7ffff9135950) at /usr/include/boost/regex/v4/match_results.hpp:74 #7 0x00000000004037d5 in boost::regex_match<std::char_traits<char>, std::allocator<char>, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > ( s=@0x7ffff9135a10, e=@0x7ffff9135a00, flags=boost::regex_constants::match_default) at /usr/include/boost/regex/v4/regex_match.hpp:93 #8 0x00000000004020d6 in main () at test.cc:10 (gdb) ======= If this is definitely not a gcc problem, I would consider moving this over to boost.
I cannot reproduce on x86_64-linux, both mainline and 4_2-branch, with the boost_regex library as provided in OpenSUSE 10.3. Anyway, the problem seems rather hard to debug because of the the boost_regex .so library. Please follow the instructions at: http://gcc.gnu.org/bugs.html try to reduce the problem as much as possible and in case also provide the exact Boost version. I would also suggest testing a gcc4.2.x release, gcc4.1.x is by now only minimally maintained.
No testcase in 3 months so closing as invalid.