stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <tvi...@quovadx.com>
Subject RE: Purify run results
Date Wed, 03 Oct 2007 23:39:35 GMT

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

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

Mime
View raw message