[1.37.0] boost test crashes under cygwin gcc-4.x
When I run a simple test application with a single (empty) BOOST_AUTO_TEST_CASE, boost test causes a crash under cygwin using gcc-4.x. It also crashes for non-empty auto test cases. For example, the boost test regressions crash: ### user-config.jam contains: using gcc : 4.3.2 : /bin/g++-4.exe ; ## cygwin gcc 4.x compiler $ cd /asl/staff/mmarcus/sandbox/boost_libraries/libs/test $ ../../tools/jam/src/bin.cygwinx86/bjam.exe gcc-4.3.2 link=static -q gives: $ ../../tools/jam/src/bin.cygwinx86/bjam.exe gcc-4.3.2 link=static -q ...patience... ...found 1528 targets... ...updating 341 targets... gcc.link ../../bin.v2/libs/test/example/unit_test_example_11.test/gcc-4.3.2/debug/link-static/unit_test_example_11 testing.capture-output ../../bin.v2/libs/test/example/unit_test_example_11.test/gcc-4.3.2/debug/link-static/unit_test_example_11.run ====== BEGIN OUTPUT ====== EXIT STATUS: 53 ====== END OUTPUT ====== (failed-as-expected) ../../bin.v2/libs/test/example/unit_test_example_11.test/gcc-4.3.2/debug/link-static/unit_test_example_11.run **passed** ../../bin.v2/libs/test/example/unit_test_example_11.test/gcc-4.3.2/debug/link-static/unit_test_example_11.test gcc.link ../../bin.v2/libs/test/example/unit_test_example_12.test/gcc-4.3.2/debug/link-static/unit_test_example_12 **passed** ../../bin.v2/libs/test/example/unit_test_example_12.test/gcc-4.3.2/debug/link-static/unit_test_example_12.test gcc.link ../../bin.v2/libs/test/example/est_example1.test/gcc-4.3.2/debug/link-static/est_example1 testing.capture-output ../../bin.v2/libs/test/example/est_example1.test/gcc-4.3.2/debug/link-static/est_example1.run ====== BEGIN OUTPUT ====== EXIT STATUS: 53 ====== END OUTPUT ====== PATH=//bin://lib://lib32://lib64:$PATH export PATH "../../bin.v2/libs/test/example/est_example1.test/gcc-4.3.2/debug/link-static/est_example1"
"../../bin.v2/libs/test/example/est_example1.test/gcc-4.3.2/debug/link-static/est_example1.output" 2>&1 status=$? echo >> "../../bin.v2/libs/test/example/est_example1.test/gcc-4.3.2/debug/link-static/est_example1.output" echo EXIT STATUS: $status >> "../../bin.v2/libs/test/example/est_example1.test/gcc-4.3.2/debug/link-static/est_example1.output" if test $status -eq 0 ; then cp "../../bin.v2/libs/test/example/est_example1.test/gcc-4.3.2/debug/link-static/est_example1.output" "../../bin.v2/libs/test/example/est_example1.test/gcc-4.3.2/debug/link-static/est_example1.run" fi verbose=0 if test $status -ne 0 ; then verbose=1 fi if test $verbose -eq 1 ; then echo ====== BEGIN OUTPUT ====== cat "../../bin.v2/libs/test/example/est_example1.test/gcc-4.3.2/debug/link-static/est_example1.output" echo ====== END OUTPUT ====== fi exit $status
...failed testing.capture-output ../../bin.v2/libs/test/example/est_example1.test/gcc-4.3.2/debug/link-static/est_example1.run... ...failed updating 1 target... ...updated 7 targets... ### Similar problems occur with when I use a manually-compiled gcc-4.3.0. In that case, my output for an empty auto test case looks like: ====== BEGIN OUTPUT ====== Running 1 test case... *** No errors detected 2 [main] any_regular_test 66836 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 413574 [main] any_regular_test 66836 open_stackdumpfile: Dumping stack trace to any_regular_test.exe.stackdump EXIT STATUS: 35584 ====== END OUTPUT ====== Stepping through in gcc shows that things run fine through the end of main, but then a problem occurs at static destruction time. My gdb skills are not sufficient to give much more info. These problems are new to 1.37.0--I've been using the unit tests successfully up through 1.36.0 (with the alt stack patch). The stack dump file for the manually-compiled gcc-4.3.0 follows. Can someone offer a suggestion? Thanks, Mat ### Exception: STATUS_ACCESS_VIOLATION at eip=610C38B4 eax=00000001 ebx=00000001 ecx=61108B2C edx=00BE0000 esi=61102F64 edi=FFFFFFF9 ebp=0022CAC8 esp=0022CA40 program=c:\asl\staff\mmarcus\sandbox\built_artifacts\test\unit_tests\any_regular\any_regular_test.test\gcc-4.3.0\debug\architecture-x86\asl-dev\instruction-set-i486\link-static\target-os-cygwin\threadapi-pthread\threading-multi\any_regular_test.exe, pid 66836, thread main cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023 Stack trace: Frame Function Args 0022CAC8 610C38B4 (004742A0, 00BE2BE0, 00000001, 004311E0) 0022CB58 00428850 (004742A0, 61102EDC, 0022CB78, 610046C2) 0022CB78 0040682F (004737DC, 61004690, 00000000, 0022CBE0) 0022CBA8 610F7DD3 (00000000, 00000000, 0022CBD8, 00000000) 0022CBC8 610E1558 (00000000, 00000000, 0022CD98, 610060E0) 0022CBD8 61004DD1 (00000000, 00BE2580, 00BE0090, 0022CB60) 0022CD98 610060E0 (00000000, 0022CDD0, 61005450, 0022CDD0) 61005450 61004416 (0000009C, A02404C7, E8611021, FFFFFF48) 2046399 [main] any_regular_test 66836 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 2114906 [main] any_regular_test 66836 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)
Mat Marcus skrev:
When I run a simple test application with a single (empty) BOOST_AUTO_TEST_CASE, boost test causes a crash under cygwin using gcc-4.x. It also crashes for non-empty auto test cases. For example, the boost test regressions crash:
Just oout of curiosity, where did you get gcc 4.x for cygwin? -Thorsten
Thorsten Ottosen wrote:
Just oout of curiosity, where did you get gcc 4.x for cygwin?
Look for the packages prefixed with 'gcc4' (not just 'gcc') in the 'Devel' category. If you wish to use it with Boost.Build v2, add the following line to your site-config.jam or user-config.jam: using gcc : : g++-4 ;
----- Original Message ----- From: "Ilya Sokolov" <ilyasokol@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, November 06, 2008 11:03 AM Subject: Re: [boost] [1.37.0] boost test crashes under cygwin gcc-4.x
Thorsten Ottosen wrote:
Just oout of curiosity, where did you get gcc 4.x for cygwin?
Look for the packages prefixed with 'gcc4' (not just 'gcc') in the 'Devel' category. If you wish to use it with Boost.Build v2, add the following line to your site-config.jam or user-config.jam:
using gcc : : g++-4 ;
Hi, please could you give the URL? Thanks, Vicente
vicente.botet skrev:
----- Original Message ----- From: "Ilya Sokolov" <ilyasokol@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, November 06, 2008 11:03 AM Subject: Re: [boost] [1.37.0] boost test crashes under cygwin gcc-4.x
Thorsten Ottosen wrote:
Just oout of curiosity, where did you get gcc 4.x for cygwin?
Look for the packages prefixed with 'gcc4' (not just 'gcc') in the 'Devel' category. If you wish to use it with Boost.Build v2, add the following line to your site-config.jam or user-config.jam:
using gcc : : g++-4 ;
Hi,
please could you give the URL?
It's the normal cygwin installer, a little further down the list. -Thorsten
----- Original Message ----- From: "Thorsten Ottosen" <thorsten.ottosen@dezide.com> To: <boost@lists.boost.org> Sent: Thursday, November 06, 2008 8:59 PM Subject: Re: [boost] [1.37.0] boost test crashes under cygwin gcc-4.x
please could you give the URL?
It's the normal cygwin installer, a little further down the list.
Thanks, Vicente
On Thu, Nov 6, 2008 at 1:26 AM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Mat Marcus skrev:
When I run a simple test application with a single (empty) BOOST_AUTO_TEST_CASE, boost test causes a crash under cygwin using gcc-4.x. It also crashes for non-empty auto test cases. For example, the boost test regressions crash:
Just oout of curiosity, where did you get gcc 4.x for cygwin?
Note that I don't find it all that useful since it seems to be compiled without posix thread support. So, in general I compile my own gcc (or concept-gcc). But I mentioned the cygwin gcc here since it will make the issue easier to reproduce. Hearing no reply from the test lib authors, I did a bit more research. It seems that if I manually register my test cases instead of using BOOST_AUTO_TEST_CASE the crashes in my tests disappear. From this I conclude that the issue lies in the additional test case destruction machinery that comes into play when the macro is used. I am rewriting my code to avoid the macro now. Though more verbose, debugging is clearer, the code is more readable, and it doesn't crash anymore. I would be interested to learn what's going wrong though. - Mat
participants (5)
-
Ilya Sokolov -
Mat Marcus -
Steven Watanabe -
Thorsten Ottosen -
vicente.botet