|
From: Oliver S. <ol...@f-...> - 2010-04-07 19:16:00
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi there,
looking over the options in memcheck I fail to find one that will
immediately issue an error as soon as I copy uninitialized memory. E.g.
I have a buffer (const char* buf) bigger than the data I read, so only n
Bytes out of n+m Bytes have been written to after the allocation (no
matter whether on the stack or not).
Whenever someone uses a Byte from buf[x] with x >= n, Valgrind will
issue an error, pointing out that an uninitialized ("tainted") value was
used to decide a condition. Fine so far.
In many cases, though, I'd already consider the first access to the
tainted Bytes (e.g. when memcpy'ing it) as errors. Is there any way to
tell Valgrind to inform me about such operations right away instead of
tracking it to the point where the memory is used for a conditional?
Or perhaps there is a good reason why Valgrind doesn't have that (given
I am not blind and the option truly doesn't exist).
Thanks in advance,
// Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
iQEcBAEBCAAGBQJLvNnnAAoJEJm+Ui/QYLFPWfsH/RPTxZLHUo0PQepyeTUafT3l
AA/C4Uqtdx4nrACGWPAWkgqdvoVl8DVrfwvWDnRUyTN+Rh53kx6Q2Td/c20DiOmK
aKfYjsex0b+X2xVzZs3KtgxTxSagNT0TxNsPpuVyDn5GsF6yY/IlcRuyLP0Fq4c/
diwGi1u7M9X5w0DNDfBGTPhqUeYMUkQOdATxratiMFEe2mfE6wJ7kq/4I95GAgd0
zpi3RLxAORj3tq6D5ONXau8GWhP9lL6CW479hWnUt7QeB/NVcRT4F3LKfOqS3Nyu
/s/WO0RHcAb45iBRPO17YzbpJEL7zk3/IutnKojtY7XJCOufC4t9BN//upFUc3Y=
=Ttxr
-----END PGP SIGNATURE-----
|
|
From: Tom H. <to...@co...> - 2010-04-07 20:14:15
|
On 07/04/10 20:15, Oliver Schneider wrote: > Or perhaps there is a good reason why Valgrind doesn't have that (given > I am not blind and the option truly doesn't exist). The good reason is that right back when valgrind was started experimentation showed that it produced far too many false positives to be useful. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Julian S. <js...@ac...> - 2010-04-07 22:23:24
|
On Wednesday 07 April 2010, Tom Hughes wrote: > On 07/04/10 20:15, Oliver Schneider wrote: > > Or perhaps there is a good reason why Valgrind doesn't have that (given > > I am not blind and the option truly doesn't exist). > > The good reason is that right back when valgrind was started > experimentation showed that it produced far too many false positives to > be useful. See http://www.valgrind.org/docs/manual/faq.html#faq.undeferrors J |
|
From: Oliver S. <ol...@f-...> - 2010-04-08 16:36:19
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi everyone. On 2010-04-07 22:40, Julian Seward wrote: > See > http://www.valgrind.org/docs/manual/faq.html#faq.undeferrors Thanks, Julian. I've been running it with --track-origins=yes most of the time, so I guess I'm out of luck. But then, Valgrind is FLOSS ;) If I would develop a patch that allows to give a command line switch that causes Valgrind to report copying immediately, would that be something that would be considered for the mainstream version? Or is it not even worth sending? // Oliver -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBCAAGBQJLvgXzAAoJEJm+Ui/QYLFPZ5AH/jyWJjsDjk1jmlBdZTJm6Wp1 Deab24YDma+fFveetQqNN2aeakyv1u6pIwLytWEqNvJS8uKyNoJmmPj74+ItoBWU aKusYA5tFIxbhs4IE1dppnl9w6+HeljVH97whX8GhvtU4s9G3BgmGC4fwzwFAPtY gOZuvhOxowJd9+om41Mij59BaHvFXHCLHTRpZVD9hX9815vU/yoYnKtd+KCMdp8t JDWMuenMG9CdVUbEeKikNOTM8VDO827ET/eW8DsO/ri3dZOdNKvLWFP6pmn8D8LA iOESogZZDwdakGiwULUIQ9YnjnSjuymZ449ByOTWTuQ/QBOAGU0yocb7LbRTAqI= =yzQq -----END PGP SIGNATURE----- |
|
From: Konstantin S. <kon...@gm...> - 2010-04-09 05:31:16
|
On Thu, Apr 8, 2010 at 8:36 PM, Oliver Schneider <ol...@f-...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi everyone. > > On 2010-04-07 22:40, Julian Seward wrote: > > See > > http://www.valgrind.org/docs/manual/faq.html#faq.undeferrors > Thanks, Julian. I've been running it with --track-origins=yes most of > the time, so I guess I'm out of luck. But then, Valgrind is FLOSS ;) > > If I would develop a patch that allows to give a command line switch > that causes Valgrind to report copying immediately, would that be > something that would be considered for the mainstream version? Or is it > not even worth sending? > The Intel Parallel Inspector behaves exactly as you describe (at least, used to behave). On the tests I usually run under memcheck, inspector reported hundreds of false positives. --kcc > > // Oliver > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > > iQEcBAEBCAAGBQJLvgXzAAoJEJm+Ui/QYLFPZ5AH/jyWJjsDjk1jmlBdZTJm6Wp1 > Deab24YDma+fFveetQqNN2aeakyv1u6pIwLytWEqNvJS8uKyNoJmmPj74+ItoBWU > aKusYA5tFIxbhs4IE1dppnl9w6+HeljVH97whX8GhvtU4s9G3BgmGC4fwzwFAPtY > gOZuvhOxowJd9+om41Mij59BaHvFXHCLHTRpZVD9hX9815vU/yoYnKtd+KCMdp8t > JDWMuenMG9CdVUbEeKikNOTM8VDO827ET/eW8DsO/ri3dZOdNKvLWFP6pmn8D8LA > iOESogZZDwdakGiwULUIQ9YnjnSjuymZ449ByOTWTuQ/QBOAGU0yocb7LbRTAqI= > =yzQq > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Nicholas N. <n.n...@gm...> - 2010-04-09 05:23:56
|
On Thu, Apr 8, 2010 at 9:36 AM, Oliver Schneider <ol...@f-...> wrote: > > If I would develop a patch that allows to give a command line switch > that causes Valgrind to report copying immediately, would that be > something that would be considered for the mainstream version? Or is it > not even worth sending? It's easy to do, but gives bazillions of warnings even for the most trivial programs. Even if you religiously avoid undefined values in your code (eg. by padding out your structs) all the libraries you use will copy undefined values around like crazy. http://www.valgrind.org/njn/pubs/memcheck2005.pdf may be worth reading for more background. Nick |
|
From: John R. <jr...@bi...> - 2010-04-09 14:53:15
|
On 04/08/2010 10:23 PM, Nicholas Nethercote wrote: > It's easy to do, but gives bazillions of warnings even for the most > trivial programs. Even if you religiously avoid undefined values in > your code (eg. by padding out your structs) all the libraries you use > will copy undefined values around like crazy. "All the libraries ... copy undefined values around like crazy" might be an exaggeration. For instance, I fixed all the instances in several generations of glibc. It was a slog at times, but not totally impossible. http://BitWagon.com/glibc-audit/glibc-audit.html The maintainers of glibc were not interested. I view that opinion as short-sighted because I see it impeding software quality. For instance, every run of memcheck is measurably more expensive due to catching and suppressing the glibc-specific uninit-but-don't-cares. I believe that avoiding a single bug per project saves many multiples of the space and cycles that are required to execute uninit-free. About once per year per programmer, the analysis even _saves_ space and cycles by identifying inefficiencies in layout or execution. Similarly to the initial work that is required when running a never- checked-before application under memcheck, then running with "no copy of uninit bits" requires significant initial work. Such work often includes libraries which the application developer probably prefers to ignore. However, the benefits of a solid foundation accrue to all clients on all runs, for as long as the library is used. Today the cost might seem high; in a while it will become quite small. In practical terms, a major library might have 20 to 30 root causes for most of its uninit copying. About a dozen or so probably will be quick and easy to identify, and then the others will be a long tail. -- |
|
From: Nicholas N. <n.n...@gm...> - 2010-04-12 05:37:29
|
On Sat, Apr 10, 2010 at 12:52 AM, John Reiser <jr...@bi...> wrote: > > "All the libraries ... copy undefined values around like crazy" > might be an exaggeration. For instance, I fixed all the instances > in several generations of glibc. It was a slog at times, but not > totally impossible. http://BitWagon.com/glibc-audit/glibc-audit.html > > In practical terms, a major library might have 20 to 30 root causes > for most of its uninit copying. About a dozen or so probably will be > quick and easy to identify, and then the others will be a long tail. There might be a moderate number of static instances, but in practice this translates into many dynamic instances. Hence the 100s of warnings on trivial programs, and my "copy undefined values around like crazy" characterisation. Nick |