Re: [Valgrind-users] How to report WHICH buffer has uninitialized data

[John R. <jr...@Bi...>]

Nicholas Nethercote wrote:
> On Wed, 8 Jun 2005, John Reiser wrote:
> 
>> Memcheck ought to have an _option_ to check and report as soon as 
>> possible:
>> immediately upon each memory fetch.  This would require patience in 
>> dealing
>> with "false positive" complaints (such as copy of structures with holes,
>> speculative loads that are later ignored, etc.) but probably it would
>> help you in this and similar cases.  Other memory checkers work this way.
> 
> 
> I've said before that I tried this once, and got hundreds of error 
> reports even for tiny programs like 'true'.  So I don't think it's 
> practical.

Other people do think it is practical.  They pay money to use it.
Purify works this way.  The no-recompile mode of Insure++ works this way.
Customers tolerate the small fraction of false positive complaints,
partly because of the bulls-eye identification of the instruction
which first loaded the uninit bits.  Some software quality policies
strongly encourage "never access uninit bits (for any reason.)"
Applying this policy to the most troublesome case (bit fields) can
_increase_ efficiency, particularly because gcc still generates
less-than-optimal code for sequences of assignments to adjacent
bit fields.

In most cases, 'true' is a shell builtin.  Running the no-recompile
mode of Insure++ on "/bin/bash -c true" reports 1 READ_UNINIT_MEM error
from __gconv_transform_utf8_internal(), and two leaks from _dl_allocate_tls_storage().
The READ_UNINIT is genuine (bash 2.05b.0(1), /lib/tls/libc-2.3.2.so).
Compiling the C code
	main() { exit(0); }
and running under the no-recompile mode of Insure++ gives no READ_UNINIT_MEM
errors, and the same two leaks.  Please give a reproducible example of
your claim of "hundreds of errors."

--