Re: [Boost-build] [EXTERNAL] Re: Boost build vacpp on Linux (PPC)

Subject: Re: [Boost-build] [EXTERNAL] Re: Boost build vacpp on Linux (PPC)
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-03-29 11:17:13

AMDG

It would help for me to actually add the
attachment.

In Christ,
Steven Watanabe

On 03/29/2012 08:14 AM, Steven Watanabe wrote:
> AMDG
> 
> On 03/28/2012 10:31 PM, Hubert Tong wrote:
>>
>> I have confirmed that compiling function.c with optimization is the key to
>> hitting the issue.
>> It seems argv/envp can affect how the failure presents itself.
>>
>> Using xlc option -qinitauto=00 (which will zero otherwise uninitialized
>> stack variables), I can get:
>>> bin.aixppc/b2 --help
>> jambase.c:76: in module scope
>> *** argument error
>> * rule find-to-root (  :  )
>> * called with:
>> ( /home/hstong/b2011/boost-trunk-2012-03-25-12-03-24-EDT/tools/build/v2/engine :
>>  boost-build.jam )
>> * extra
>> argument /home/hstong/b2011/boost-trunk-2012-03-25-12-03-24-EDT/tools/build/v2/engine
>> jambase.c:11:see definition of rule 'find-to-root' being called
>> Return:  0x01:1
>>
> 
> Okay. So I was off-by-one on the line number.
> The problem appears to be either in arg_list_compile
> or in argument_list_push.
> 
> A few more things that would help:
> 
> a) The output with the attached patch
>    (There may be a lot.  I only need the output for
>    find-to-root)
> 
> b) The output when run under valgrind --track-origins=yes
> 
> c) A mixed assembler/source dump for function.c.  (The
>    problem is sufficiently isolated now that I should
>    be able to track down the problem with only this.)
> 
>> Here is the debugger trace without -qinitauto=00 (I replaced struct _object
>> with char to get better output):
>> Segmentation fault in list_end at line 120 in file "lists.c"
>>   120           return list_begin( l ) + l->impl.size;
>> (dbx) where
>> list_end(l = 0xdeadbeef), line 120 in "lists.c"
>> type_check(type_name = "", values = (nil), caller = 0x00000020, called =
>> 0x0000c128, arg_name = (nil)), line 2686 in "function.c"
> 
> So the stack is totally broken.  I really hope
> that this is mostly a result of incorrect debug
> info, because l in frame 0, should be the same
> as values in frame 1.
> 
> In Christ,
> Steven Watanabe