You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Andrew Black <ab...@roguewave.com> on 2007/10/01 23:01:52 UTC
Purify run results
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
RE: Purify run results
Posted by Travis Vitek <tv...@quovadx.com>.
>From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>
>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.
>
>The UMR is real, isn't it? I.e., __tag is not initialized but
>it's being copied to the function argument.
Yes, I agree that it is real. The empty object is allocated on the
stack, but that stack space is not initialized with anything. i.e. The
compiler generates code that results in a UMR reported by Purify. Got
any bright ideas on how to fix it from C++ without adding a data member
to the empty object?
I can easily ignore the hundreds of UMR warnings that are caused by the
problem, but others looking at the purify results should be made aware
that there doesn't really appear to be anything _reasonable_ that we can
do about it.
Interestingly enough, Purify on HP does _not_ report a UMR if I just
copy the tag object that is not uninitialized...
;;; File: t.cpp
;;; 15 {
0x2cec <main>: nop
0x2cf0 <main+0x4>: stw %rp,-0x14(%sp)
0x2cf4 <main+0x8>: ldo 0x40(%sp),%sp
0x2cf8 <main+0xc>: call 0x2cdc <_main>
0x2cfc <main+0x10>: nop
;;; 18 random_access_iterator_tag __tag2(__tag);
0x2d00 <main+0x14>: ldb -0x38(%sp),%r1 ; <- load __tag into r1
0x2d04 <main+0x18>: stb %r1,-0x37(%sp) ; <- store r1 into __tag2
;;; 19 random_access_iterator_tag __tag3(__tag2);
0x2d08 <main+0x1c>: ldb -0x37(%sp),%r31 ; <- load __tag2 into r31
0x2d0c <main+0x20>: stb %r31,-0x36(%sp) ; <- store r31 into __tag3
;;; 21 return 0;
0x2d10 <main+0x24>: ldi 0,%ret0
;;; 22 }
0x2d14 <main+0x28>: copy %ret0,%ret0
0x2d18 <main+0x2c>: ldw -0x54(%sp),%rp
0x2d1c <main+0x30>: ret
End of assembler dump.
>
>Do other compilers eliminate the copy?
>
No.
Purify for Windows does not report a UMR on the same code, but I don't
see anything in the assembly that initializes the empty object there
either.
int main()
{
00411920 push ebp
00411921 mov ebp,esp
00411923 push ecx
random_access_iterator_tag __tag;
distance (__tag); // <-- umr here
00411924 mov al,byte ptr [__tag]
00411927 push eax
00411928 call distance (40101Eh)
0041192D add esp,4
return 0;
00411930 xor eax,eax
}
00411932 mov esp,ebp
00411934 pop ebp
00411935 ret
Purify on linux/gcc reports no UMR warnings with my testcase either. I
tried to parse through the assembly generated by gcc, but it was insane.
It turned that simple main into 185 instructions. MSVC boils it down to
the 11 instructions above.
I did find that I got very similar UMR errors with std::bind1st/bind2nd
on linux/gcc. The first parameter passed to these functions is usually
an empty function object, and the UMR is reported when copying that. So
it is essentially the same problem, just a different context.
It looks like Purify is trying to detect and ignore the issue of the
uninitialized empty object [that must be at least 1 byte in size], but
it doesn't always do so.
Travis
Re: Purify run results
Posted by Martin Sebor <se...@roguewave.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
>>
>>
>
RE: Purify run results
Posted by Travis Vitek <tv...@quovadx.com>.
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
>
>