Boost logo

Boost Testing :

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

Hi Steven,

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:


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

==31979== Warning: client switching stacks? SP change: 0x623C430 -->
==31979== to suppress, use: --max-stackframe=119799728 or

So doing as valgrind suggests and rerunning with --max-stackframe
leads to an internal corruption in valgrind, as you can see here:

$ valgrind --max-stackframe=119799728 bin.v2/libs/test/test/


Memcheck: the 'impossible' happened:
    create_MAC_Chunk: shadow area is accessible
==32038== at 0x700112DF: report_and_quit (m_libcassert.c:122)
==32038== by 0x7001156D: panic (m_libcassert.c:195)
==32038== by 0x7001161E: vgPlain_tool_panic (m_libcassert.c:210)
==32038== by 0x70001380: create_MAC_Chunk (mac_malloc_wrappers.c:146)
==32038== by 0x70001582: vgMAC_malloc (mac_malloc_wrappers.c:203)
==32038== by 0x700376F0: do_client_request (scheduler.c:987)
==32038== by 0x70037050: vgPlain_scheduler (scheduler.c:721)
==32038== by 0x7004C9C9: thread_wrapper (syswrap-linux.c:86)
==32038== by 0x7004CAF4: run_a_thread_NORETURN (syswrap-linux.c:119)

So it seems that either the pathscale compiler is generating bad
code, or that this test is doing something funky that corrupts memory
in the parent process (which, in our case, is either the build system
that is running this test (prg_exec_fail2) or, as in this email,
valgrind that is running this test). Either way, it seems that the
parent process is getting hosed when running this program. I'll need
a little help (Gennadiy??) to understand what this is doing (I've
copied Gennadiy on this reply).

-- Noel

Boost-testing list run by mbergal at