Boost Testing :
Subject: Re: [Boost-testing] pathscale 3.1 reporting problems?
From: K.Noel Belcourt (kbelco_at_[hidden])
Date: 2009-06-16 17:15:10
On Jun 16, 2009, at 2:40 PM, K. Noel Belcourt wrote:
> On Jun 13, 2009, at 12:02 PM, Steven Watanabe wrote:
>> According to http://tinyurl.com/nunary, the test library fail to
>> but following the
>> link, it appears that the test library did build correctly. Any
> Well that's a strange problem. This executable:
> is built and runs to completion, apparently without error. But, as
> Steven points out, the test results reported in the trunk tests
> reports a failure.
> I'm just guessing that this program somehow corrupts memory. Does
> anyone know if this program manipulates the stack frame or expects
> a very large stack? The reason I ask is this error message from
> valgrind, when running prg_exec_fail2, seems to show something
> funky with the stack (120 Mb stack change is pretty huge by most
Alright, I've learned a few things about Boost.test.
First, it doesn't recognize the Etnus' Totalview debugger so inside
debug.ipp in the BOOST_UNIX_BASED_DEBUG macro block, only gdb is in
the dbg_list, so this code can't be effectively debugged under
Totalview (the Totalview program name is version specific, tv8main in
Second, in execution_monitor.ipp, catch_signals(), it appears that we
must disable macro BOOST_TEST_USE_ALT_STACK. Can someone (Gennadiy?)
please disable this macro (and all this alternate stack code) in the
trunk when building for pathscale-3.1 to see if this fixes the problem?
And just a general question, is all this complexity (recognizing
debuggers, managing alternate stacks, etc...) really necessary for a