Markus Schöpflin wrote:
I have no idea. But the thread libs regression tests are all passing.
Looking more closely at the call stack, it seems corrupted. Especially interesting is frame #14:
#14 0x0000000120191338 in boost::re_detail::basic_regex_parser<char, boost::cpp_regex_traits<char> >::parse (this=0x0, p1=0x140122180 "@¡\023@\001", p2=0x12019178c "ø\037º'd\207½#P", l_flags=1074929976) at ../../../boost/regex/v4/basic_regex_parser.hpp:125
The this pointer is NULL here. And further up we have more strange values. I have to admit I'm a little lost here.
I do get a warning when compiling the tests about some signed/unsigned conversion issues. Maybe this is related?
Very unlikely: the function backtrace is what I would expect, modulo the corrupt addresses. Indeed the "this" address is apparently different on every call! The regex being compiled is correct on the first basic_regex::assign call, but corrupt thereafter, although the call stack is what I would expect to see for the program path for that test. So maybe the stack is corrupted after the exception is thrown? I'm not completely sure, but I don't see any thrown exceptions being tested in the thread-lib tests. I do know that I've seen exceptions doing strange things with gcc in the past when threads were either unsupported, or only partly supported. If I get a chance I'll try and put together a simpler test case, but I'm basically stumped at present. Thanks for the help, John.