Re: [Boost-testing] pathscale 3.1 reporting problems?

Subject: Re: [Boost-testing] pathscale 3.1 reporting problems?
From: K.Noel Belcourt (kbelco_at_[hidden])
Date: 2009-06-16 17:15:10

Hi Steven,

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  
>> build,
>> but following the
>> link, it appears that the test library did build correctly.  Any  
>> ideas?
>
> Well that's a strange problem.  This executable:
>
> 	bin.v2/libs/test/test/prg_exec_fail2.test/pathscale-3.1/debug/ 
> prg_exec_fail2
>
> 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  
> measures).

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  
our case).

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  
testing library?

-- Noel