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: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Purify run results
Date: Wed, 3 Oct 2007 17:39:35 -0600
Message-ID: 
 <C8506D6098A6F545BA3745D0CE359E8301A1D580@qxvcexch01.ad.quovadx.com>
In-Reply-To: <47016040.40107@roguewave.com>
Thread-Topic: Purify run results
Thread-Index: AcgEbruHx6v/tOQ/TN2Sfl45sT7VwwBnwdUg
References: <47016040.40107@roguewave.com>
From: "Travis Vitek" <tvitek@quovadx.com>
To: <stdcxx-dev@incubator.apache.org>


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
{=20
#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

    return 0;
}

[vitek@blokus ~]$ purify -log-file=3Dt.log -windows=3Dno aCC        -g =
t.cpp
2> /dev/null && ./a.out && grep "^UMR" t.log
UMR: Uninitialized memory read:
[vitek@blokus ~]$ purify -log-file=3Dt.log -windows=3Dno aCC -D_TAG -g =
t.cpp
2> /dev/null && ./a.out && grep "^UMR" t.log
[vitek@blokus ~]$=20

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=20
>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=3D$@.log
>-windows=3Dno -append-logfile=3Dyes -view-file=3D$@.pfy
>-always-use-cache-dir=3Dyes -cache-dir=3D/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=20
>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
>
>