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 16:40:04

Hi Steven,

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

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

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/ 
prg_exec_fail2.test/pathscale-3.1/debug/prg_exec_fail2

....

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