::parse_extended (this=0xffde311c) at /usr/include/boost/regex/v4/basic_regex_parser.hpp:235 235 switch*this->m_traits.syntax_type(*m_position)) (gdb) print m_position $1 = 0x0 (gdb) bt #0 0x08066beb in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > ::parse_extended at /usr/include/boost/regex/v4/basic_regex_parser.hpp:235 #1 0xf7f9e364 in boost ::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse () from /usr/lib/libboost_regex.so.2 #2 0xf7fa0eba in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::do_assign () from /usr/lib/
Hello all, I've got what I suspect is a relatively unique problem that's resulting in a segfault whenever I try to construct a boost::regex. First some machine information: Red Hat Enterprise Linux Server release 5.1 (Tikanga) Linux 2.6.18-53.el5, SMP, x86_64 gcc 4.1.2 20070626 (Red Hat 4.1.2-14) boost 1.33.1-10 Here's a small example that shows the problem: #include <boost/algorithm/string/regex.hpp> #include <iostream> #include <string> using namespace std; int main() { string input ("test test1 test2 test3"); string pattern ("\\btest\\b"); erase_regex (input, boost::regex (pattern)); cout << input << endl; // expecting " test1 test2 test3" return 0; } Compile flags (and this is getting to the heart of the problem, I think): -g -m32 -malign-double -O3 -Wall -lboost_regex Put all the above together in a bag, shake it up, and you get this segfault: 0x08066beb in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > libboost_regex.so.2 #3 0x08050789 in main () at /usr/include/boost/regex/v4/ basic_regex.hpp:254 So the immediate culprit is a dereferencing-null problem. Interestingly, the problem goes away at -O, -O1, and -O2. Or -O3 but without -malign-double. I was wondering if this is a known problem, and if anyone else who's hand is forced to compile with -malign-double has seen this problem and been able to work around it? -- Andrew Troschinetz Applied Research Laboratories