|
Boost Testing : |
Subject: Re: [Boost-testing] Darwin/Sandia-intel - looks very problematic
From: Belcourt, Kenneth (kbelco_at_[hidden])
Date: 2011-07-14 16:50:19
Hi Artyom,
On Jul 14, 2011, at 1:43 AM, Artyom Beilis wrote:
> It seems that there is a problem with Darwin/Sandia-intel 11 and 12
> compilers - there are lots of faults all over boost libraries
> that most of them are segmentation faults even for
> libraries that has clear record on other platforms compilers.
>
> It looks like there is a problem with installation/configuration
> of these Intel compilers, maybe some ABI clash of some libraries.
A year ago I reported to the list and Gennadiy that there was some kind of infinite recursion in the exception handler in Boost.Test that impacted the Sandia Darwin Intel tester. See my email of last May. I don't think we ever found the actual problem and I suspect it's this same issue impacting many of the other Boost libraries tested with the Sandia Darwin Intel tester.
-- Noel
On May 18, 2010, at 3:12 PM, Belcourt, Kenneth wrote:
> Hi,
>
> The Sandia Darwin Intel testers have been stable for some time but a
> recent change seems to have broken the tester. This test in
> Boost.Test, seems to be the source of the problem (test_tools_test).
>
> brisc: kbelco$ pwd
> /Volumes/Scratch/kbelco/boost/results/boost/bin.v2/libs/test/test/
> test_tools_test.test/intel-darwin-11.0/debug
>
> brisc: kbelco$ more test_tools_test.output
> terminate called after throwing an instance of 'boost::system_error'
> Running 22 test cases...
> terminate called recursively
> terminate called recursively
> terminate called recursively
> terminate called recursively
> [ this message repeated until the test timed out after 5 minutes ]
>
> The test output file size is 260Mb.
>
> -rw-r--r-- 1 kbelco SANDIA\domain users 262252256 May 18 14:13
> test_tools_test.output
>
> This problem causes process_jam_log to loop indefinitely trying to
> digest this enormous output file. Could Gennadiy or anyone else
> please take a look and see if there's a way to stop the infinite
> looping of "terminate called recursively".
>
> Thanks.
>
> -- Noel