Boost logo

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

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, 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

Boost-testing list run by mbergal at