Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 209.85.146.181 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=q9mfVrxpm2OFEhcIdT4qETuycD0s8SA5NDPowfR/55oXOEpoqLEOmDJcZiqHisWgFMSEIowISbEHefOMRGj/S03rBKxSdfJ933SzAdHDHQlb3Xfy44jfUJmeUKEu1oDnvbQH+n+0ITMK7fPaFbdUgVto2otZAIpfUbmAYKOdn/o=
Message-ID: <470583DE.4040104@roguewave.com>
Date: Thu, 04 Oct 2007 14:22:54 -1000
From: Martin Sebor <sebor@roguewave.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: Purify run results
References: <47016040.40107@roguewave.com>
 <C8506D6098A6F545BA3745D0CE359E8301A1D580@qxvcexch01.ad.quovadx.com>
In-Reply-To: 
 <C8506D6098A6F545BA3745D0CE359E8301A1D580@qxvcexch01.ad.quovadx.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Travis Vitek wrote:
> I spent some time looking through these results and it looks like the HP
> compiler is generating code that results in many unexpected UMR
> [Uninitialized Memory Read] errors. I'm not exactly sure what to do with
> the information I've gathered, so I'm posting it here. Here is my simple
> testcase and other relevant information.
> 
> [vitek@blokus ~]$ cat t.cpp
> 
> struct random_access_iterator_tag
> { 
> #ifdef _TAG
>     random_access_iterator_tag () : _C_dummy(0) {}
>     char _C_dummy;
> #endif
> };
> 
> void distance(random_access_iterator_tag)
> {
> }
> 
> int main()
> {
>     const random_access_iterator_tag __tag;
>     distance (__tag); // <-- umr here

The UMR is real, isn't it? I.e., __tag is not initialized but
it's being copied to the function argument. Do other compilers
eliminate the copy?

Martin

> 
>     return 0;
> }
> 
> [vitek@blokus ~]$ purify -log-file=t.log -windows=no aCC        -g t.cpp
> 2> /dev/null && ./a.out && grep "^UMR" t.log
> UMR: Uninitialized memory read:
> [vitek@blokus ~]$ purify -log-file=t.log -windows=no aCC -D_TAG -g t.cpp
> 2> /dev/null && ./a.out && grep "^UMR" t.log
> [vitek@blokus ~]$ 
> 
> Here is the purify message...
> 
> UMR: Uninitialized memory read:
>   * This is occurring while in:
>         main           [t.cpp:17]
>         _start         [libc.2]
>         $START$        [crt0.o]
>         $START$        [crt0.o]
>   * Reading 1 byte from 0x7f7f0b88 on the stack.
>   * Address 0x7f7f0b88 is local variable "__tag" in function main.
> 
> Here is the disassembly for the original code. You can see that a byte
> from -0x38(%sp) is loaded into %r17, but nothing was ever stored there.
> 
> 0x5296c <main+0x20>:    nop
> 0x52970 <main+0x24>:    call,n 0x5293c <_main>
> 0x52974 <main+0x28>:    break 0,0
> 0x52978 <main+0x2c>:    be,l -0xdd8(%sr3,%r18),%sr0,%r31
> 0x5297c <main+0x30>:    copy %sp,%r17
> ;;;  17     distance (__tag);
> 0x52980 <main+0x34>:    be,l -0xfb8(%sr3,%r18),%sr0,%r31
> 0x52984 <main+0x38>:    ldo -0x38(%sp),%r17 ; <-- load here, but no
> previous store
> 0x52988 <main+0x3c>:    ldb -0x38(%sp),%r26 ; <-- load here, but no
> previous store
> 0x5298c <main+0x40>:    be,l,n -0xdfc(%sr3,%r18),%sr0,%r31
> 0x52990 <main+0x44>:    nop
> 
> Here is the disassembly for the case that gets no UMR message. You can
> see that a byte is stored at -0x38(%sp) before it is loaded.
> 
> 0x5296c <main+0x20>:    nop
> 0x52970 <main+0x24>:    call,n 0x5293c <_main>
> 0x52974 <main+0x28>:    break 0,0
> 0x52978 <main+0x2c>:    be,l -0xdd8(%sr3,%r18),%sr0,%r31
> 0x5297c <main+0x30>:    copy %sp,%r17
> ;;;  16     const random_access_iterator_tag __tag;
> 0x52980 <main+0x34>:    be,l -0xef8(%sr3,%r18),%sr0,%r31
> 0x52984 <main+0x38>:    ldo -0x38(%sp),%r17
> 0x52988 <main+0x3c>:    stb %r0,-0x38(%sp) ; <-- store here
> ;;;  17     distance (__tag);
> 0x5298c <main+0x40>:    be,l -0xfb8(%sr3,%r18),%sr0,%r31
> 0x52990 <main+0x44>:    ldo -0x38(%sp),%r17 ; <-- load here
> 0x52994 <main+0x48>:    ldb -0x38(%sp),%r26 ; <-- load here
> 0x52998 <main+0x4c>:    be,l,n -0xdfc(%sr3,%r18),%sr0,%r31
> 0x5299c <main+0x50>:    nop
> 
> This issue causes Purify warnings in any function that passes an empty
> class as a parameter to a function by value. Nearly any function that
> touches the iterator tag types will give a UMR warning because of this
> problem.
> 
> Travis
> 
>> From: Andrew Black
>>
>> Greetings all.
>>
>> As I mentioned in my previous email, I've performed a test build of the
>> apache standard library using Rational
>> PurifyPlus 7.0 ( http://www.ibm.com/software/awdtools/purifyplus/ ).
>> This build was performed on an HPUX 11.23 machine, using the 
>> HP acc 3.73
>> compiler and subversion trunk at
>> r580086 plus the makefile.rules part of the purify.diff patch attached
>> to STDCXX-573.  PURE_OPTS was set to '-log-file=$@.log
>> -windows=no -append-logfile=yes -view-file=$@.pfy
>> -always-use-cache-dir=yes -cache-dir=/tmp/ablack-purecache-stdcx'.  If
>> anyone wishes to look at the results of this build, it can be retrieved
>>from http://people.apache.org/~ablack/stdcxx-4.2.0-rc-5-purify.tar.gz .
>> This build was a 15d build, which was processed with `make clean` and
>> `make dependclean` prior to being compressed.
>>
>> Note that some of the .log files were truncated by Purify 
>> during the run
>> process due to their length.  These files are
>> 22.locale.money.put.log, tests/22.locale.moneypunct.log,
>> tests/22.locale.num.get.log, tests/23.deque.modifiers.log,
>> tests/25.find.end.log, and tests/25.search.log.
>>
>> --Andrew Black
>>
>>
>