[regrex] Failure on newly added test regex_regress_threaded on Tru64/GCC
For reference, see http://tinyurl.com/rm4dr and http://tinyurl.com/k53v2. Interestingly enough, the test passes on Tru64/CXX. Compiled with gcc 4.0.3 the test aborts with 'terminate called recursively', compiled with 3.4.4 it throws a SIGABRT. Is there anything I can do to help in debugging? Markus
Markus Schöpflin wrote:
For reference, see http://tinyurl.com/rm4dr and http://tinyurl.com/k53v2.
Interestingly enough, the test passes on Tru64/CXX. Compiled with gcc 4.0.3 the test aborts with 'terminate called recursively', compiled with 3.4.4 it throws a SIGABRT.
Is there anything I can do to help in debugging?
Thanks Marcus, I had spotted that failure, but didn't know what to do about it. The fact that it's specific to gcc on that one specific platform is particulary frustrating! I have to be honest: I'm not even sure how to go about debugging this: basically the test program spawns 10 threads each of which then runs the regex test code. In other words it's a stress-test to detect multi-threading issues. Are there any known problems with gcc and threading on that platform? Failing that, if you can run it under gdb and see what traps that might suggest something. And finally, is gcc on tru64 available on the HP testdrive machines? I had a quick look last week, but couldn't see anything? Many thanks, John.
John Maddock wrote:
Markus Schöpflin wrote:
For reference, see http://tinyurl.com/rm4dr and http://tinyurl.com/k53v2.
Interestingly enough, the test passes on Tru64/CXX. Compiled with gcc 4.0.3 the test aborts with 'terminate called recursively', compiled with 3.4.4 it throws a SIGABRT.
Is there anything I can do to help in debugging?
Thanks Marcus, I had spotted that failure, but didn't know what to do about it. The fact that it's specific to gcc on that one specific platform is particulary frustrating!
I have to be honest: I'm not even sure how to go about debugging this: basically the test program spawns 10 threads each of which then runs the regex test code. In other words it's a stress-test to detect multi-threading issues. Are there any known problems with gcc and threading on that platform?
With gcc 4.1 and later multi threading is simply broken on Tru64. But it should work with earlier version. IIRC, 3.x uses DEC threads and 4.x uses POSIX threads. That might explain the different behaviors we're observing.
Failing that, if you can run it under gdb and see what traps that might suggest something.
Hmm, gdb doesn't work reliable for Tru64, AFAIK. I'll try with ladebug or dbx. I'll post here if I find anything useful.
And finally, is gcc on tru64 available on the HP testdrive machines? I had a quick look last week, but couldn't see anything?
I have a private installation of gcc 3.4.4 on one of the test drive machines. But HP test drive is going to retire Tru64 anyway, so this won't be of much use anymore. I received an offer from HP to get access to a machine outside the test drive program to keep the Tru64 boost regression tests alive as I don't have the local capacity to run all the tests on our machine, but this might take a few more days and probably needs some more details sorted out. Markus
Markus Schöpflin wrote:
John Maddock wrote:
Markus Schöpflin wrote:
For reference, see http://tinyurl.com/rm4dr and http://tinyurl.com/k53v2.
Interestingly enough, the test passes on Tru64/CXX. Compiled with gcc 4.0.3 the test aborts with 'terminate called recursively', compiled with 3.4.4 it throws a SIGABRT.
Is there anything I can do to help in debugging?
Thanks Marcus, I had spotted that failure, but didn't know what to do about it. The fact that it's specific to gcc on that one specific platform is particulary frustrating!
I have to be honest: I'm not even sure how to go about debugging this: basically the test program spawns 10 threads each of which then runs the regex test code. In other words it's a stress-test to detect multi-threading issues. Are there any known problems with gcc and threading on that platform?
With gcc 4.1 and later multi threading is simply broken on Tru64. But it should work with earlier version. IIRC, 3.x uses DEC threads and 4.x uses POSIX threads. That might explain the different behaviors we're observing.
Oh, hold on: regex uses POSIX threads, come to that so does Boost.Threads and the test driver program. However, the threads lib tests all pass so I assumed it wasn't an issue as simple as this. So is this just a case of "not supported"? John.
John Maddock wrote:
Markus Schöpflin wrote:
John Maddock wrote: ...
I have to be honest: I'm not even sure how to go about debugging this: basically the test program spawns 10 threads each of which then runs the regex test code. In other words it's a stress-test to detect multi-threading issues. Are there any known problems with gcc and threading on that platform? With gcc 4.1 and later multi threading is simply broken on Tru64. But it should work with earlier version. IIRC, 3.x uses DEC threads and 4.x uses POSIX threads. That might explain the different behaviors we're observing.
Oh, hold on: regex uses POSIX threads, come to that so does Boost.Threads and the test driver program. However, the threads lib tests all pass so I assumed it wasn't an issue as simple as this. So is this just a case of "not supported"?
I'm sorry, but I don't understand at all what you are trying to tell me. Could you please rephrase that somehow? Thanks, Markus
John Maddock wrote:
Failing that, if you can run it under gdb and see what traps that might suggest something.
I did not yet run it under any debugger, but I got the following output when running the test manually using gcc 4.0.3. Maybe this does ring a bell for you. testing.capture-output ../../../bin.v2/libs/regex/test/regex_regress_threaded.test/gcc-4_0_3_tru64/debug/threading-multi/regex_regress_threaded.run /bin/sh: 475572 Memory fault - core dumped ====== BEGIN OUTPUT ====== terminate called recursively terminate called after throwing an instance of 'boost::regex_error' what(): Unmatched ( or \( **** exception(210): signal: SIGABRT (application abort requested) ******** errors detected; see standard output for details ******** EXIT STATUS: 139 ====== END OUTPUT ====== Markus
John Maddock wrote:
Failing that, if you can run it under gdb and see what traps that might suggest something.
And here is the stack trace when running the program on gdb: (gdb) run Starting program: /vol2/boost/src/boost-RC_1_34_0/bin.v2/libs/regex/test/regex_regress_threaded.test/gcc-4_0_3_tru64/debug/threading-multi/regex_regress_threaded terminate called after throwing an instance of 'boost::regex_error' what(): Unmatched ( or \( Program received signal SIGABRT, Aborted. 0x000003ff805c1ac8 in __nxm_thread_kill () from /usr/shlib/libpthread.so (gdb) where #0 0x000003ff805c1ac8 in __nxm_thread_kill () from /usr/shlib/libpthread.so #1 0x000003ff805ba124 in pthread_kill () from /usr/shlib/libpthread.so #2 0x000003ff80140238 in tis_raise () from /usr/shlib/libc.so #3 0x000003ff801d21fc in abort () from /usr/shlib/libc.so #4 0x00000300000f8c88 in __gnu_cxx::__verbose_terminate_handler () at /home/schoepf/local/src/gcc-4.0.3/libstdc++-v3/libsupc++/vterminate.cc:97 #5 0x00000300000f5950 in __cxxabiv1::__terminate (handler=0x3ff801adcd0 <raise>) at /home/schoepf/local/src/gcc-4.0.3/libstdc++-v3/libsupc++/eh_terminate.cc:43 #6 0x00000300000f59cc in std::terminate () at /home/schoepf/local/src/gcc-4.0.3/libstdc++-v3/libsupc++/eh_terminate.cc:53 #7 0x00000300000f5b5c in __cxa_throw (obj=0x0, tinfo=0x6, dest=0x1) at /home/schoepf/local/src/gcc-4.0.3/libstdc++-v3/libsupc++/eh_throw.cc:77 #8 0x000003ffbff45dd8 in boost::throw_exception<boost::regex_error> (e=@0x2000141b9b8) at ../../../boost/throw_exception.hpp:39 #9 0x000003ffbff45e2c in boost::regex_error::raise (this=0x1201732ec) at ../../../libs/regex/src/../src/regex.cpp:76 #10 0x00000001201732ec in boost::re_detail::basic_regex_parser<char, boost::cpp_regex_traits<char> >::fail (this=0x1200f61c8, error_code=21084752, position=5369995776) at ../../../boost/regex/v4/basic_regex_parser.hpp:160 #11 0x0000000120174c80 in boost::re_detail::basic_regex_parser<char, boost::cpp_regex_traits<char> >::parse_open_paren (this=0x2000141bc01) at ../../../boost/regex/v4/basic_regex_parser.hpp:335 #12 0x00000001201a85a0 in boost::re_detail::basic_regex_parser<char, boost::cpp_regex_traits<char> >::parse_extended (this=0x2000141bc08) at ../../../boost/regex/v4/basic_regex_parser.hpp:238 #13 0x00000001200f1f28 in boost::re_detail::basic_regex_parser<char, boost::cpp_regex_traits<char> >::parse_all (this=0x2000141bb78) at ../../../boost/regex/v4/basic_regex_parser.hpp:173 #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 #15 0x00000001201914b4 in boost::re_detail::basic_regex_implementation<char, boost::cpp_regex_traits<char> >::assign (this=0x12019192c, arg_first=0x2000141bd20 "`\035\031 \001", arg_last=0x2000141be80 "\200f\021@\001", f=1074929976) at ../../../boost/regex/v4/basic_regex.hpp:96 #16 0x000000012019178c in boost::basic_regex<char, boost::cpp_regex_traits<char> >::do_assign (this=0x140122139, p1=0x100000000 <Address 0x100000000 out of bounds>, p2=0x120191d60 "ø\037º'\220\201½#£\001àÃ`", f=1074633374) at ../../../boost/regex/v4/basic_regex.hpp:524 #17 0x0000000120191870 in boost::basic_regex<char, boost::cpp_regex_traits<char> >::assign (this=0x2000141be80, p1=0x140122138 "(", p2=0x140122139 "", f=0) at ../../../boost/regex/v4/basic_regex.hpp:255 #18 0x000000012019192c in boost::basic_regex<char, boost::cpp_regex_traits<char> >::assign<std::char_traits<char>, std::allocator<char> > ( this=0x20000000000, s=@0x8, f=538531772) at ../../../boost/regex/v4/basic_regex.hpp:293 #19 0x0000000120191d60 in test<char, boost::cpp_regex_traits<char> > (r=@0x300000cbf28) at regress/test_not_regex.hpp:78 #20 0x00000001201957bc in do_test<char, test_invalid_regex_tag> (c=@0x3, tag=@0x3) at regress/test.hpp:72 #21 0x0000000120195db8 in test (c=@0x1200c6ef0, tag=@0x2000141bef0) at regress/main.cpp:167 #22 0x00000001200c6ef0 in basic_tests () at regress/basic_tests.cpp:44 #23 0x00000001200dc794 in run_tests () at regress/main.cpp:38 #24 0x00000001200ea758 in boost::detail::function::void_function_invoker0<void (*)(), void>::invoke (function_ptr=@0x2000141dbc0) at ../../../boost/function/function_template.hpp:104 #25 0x000003ffbffefd58 in boost::function0<void, std::allocator<boost::function_base> >::operator() (this=0x3ff805cf53c) at ../../../boost/function/function_template.hpp:682 #26 0x000003ffbfff0688 in thread_proxy (param=0x2000141f440) at ../../../libs/thread/src/thread.cpp:113 #27 0x000003ff805cf53c in __thdBase () from /usr/shlib/libpthread.so #28 0x0000000000000000 in ?? () [...] warning: Hit heuristic-fence-post without finding warning: enclosing function for address 0x800000000000000 This warning occurs if you are debugging a function without any symbols (for example, in a stripped executable). In that case, you may wish to increase the size of the search with the `set heuristic-fence-post' command.
Markus Schöpflin wrote:
John Maddock wrote:
Failing that, if you can run it under gdb and see what traps that might suggest something.
And here is the stack trace when running the program on gdb:
There seems to be a problem then with exceptions when thrown from a running thread not getting caught by the appropriate handler - I can assure you that there *is* a handler present for exceptions of type regex_error, indeed the code for the multithreaded case is no different from the single threaded one. Is this a known gcc problem? Thanks Markus, John.
John Maddock wrote:
Markus Schöpflin wrote:
John Maddock wrote:
Failing that, if you can run it under gdb and see what traps that might suggest something. And here is the stack trace when running the program on gdb:
There seems to be a problem then with exceptions when thrown from a running thread not getting caught by the appropriate handler - I can assure you that there *is* a handler present for exceptions of type regex_error, indeed the code for the multithreaded case is no different from the single threaded one. Is this a known gcc problem?
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? Markus
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.
participants (2)
-
John Maddock -
Markus Schöpflin