Thread: [Valgrind-users] Question about uninitialized references

Brought to you by: njn, sewardj, wielaard

valgrind-users

[Valgrind-users] Question about uninitialized references

From: Leonard m. <spa...@ya...> - 2003-06-10 14:45:35

#include <stdio.h>

struct stuff
{
  double value;
};


int main()
{
  stuff prev,curr;

  //curr.value = 0;
  prev = curr;
  curr.value = 1;
  if ( prev.value != curr.value )
    printf( "Different\n" );
}

In the above example, prev = curr doesn't generate a ref to uninit data
warning.  But the condition on the if line does.

Just a curious question.  What is valgrind's test for "dealing"
with uninitialized data?  It appears reading it moving it around 
is OK, but using it to perform "a computation" is an error?  But 
what is "a computation" in this context?

This guess seems consistent with the fact that valgrind doesn't flag
passing uninitialized data to a function so long as the parameter isn't
used.  But I'd like to know the full story.

Thanks,

Randall


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Re: [Valgrind-users] Question about uninitialized references

From: Nicholas N. <nj...@ca...> - 2003-06-10 14:58:54

On Tue, 10 Jun 2003, Leonard mckinley wrote:

> Just a curious question.  What is valgrind's test for "dealing"
> with uninitialized data?  It appears reading it moving it around
> is OK, but using it to perform "a computation" is an error?  But
> what is "a computation" in this context?

validity is checked when a value is:

1. used in a condition (affects control flow)

2. used by a syscall (ie. argument) (affects side effects seen by outside
   world)

That's it.  It might not seem like much, but it's enough, if you think
about it - that catches all cases where an invalid value can affect the
behaviour of your program, as viewed by the outside world.

Note especially that structs can have "holes" in them (due to padding
inserted by the compiler to improve field alignments) so copying has to be
ok.

> This guess seems consistent with the fact that valgrind doesn't flag
> passing uninitialized data to a function so long as the parameter isn't
> used.  But I'd like to know the full story.

N

Re: [Valgrind-users] Question about uninitialized references

From: Jeremy F. <je...@go...> - 2003-06-10 16:33:05

On Tue, 2003-06-10 at 07:58, Nicholas Nethercote wrote:
> validity is checked when a value is:
> 
> 1. used in a condition (affects control flow)
> 
> 2. used by a syscall (ie. argument) (affects side effects seen by outside
>    world)

And when it is used as a pointer.

    J

Re: [Valgrind-users] Question about uninitialized references

From: Nicholas N. <nj...@ca...> - 2003-06-10 16:38:18

On 10 Jun 2003, Jeremy Fitzhardinge wrote:

> On Tue, 2003-06-10 at 07:58, Nicholas Nethercote wrote:
> > validity is checked when a value is:
> >
> > 1. used in a condition (affects control flow)
> >
> > 2. used by a syscall (ie. argument) (affects side effects seen by outside
> >    world)
>
> And when it is used as a pointer.

Oh yeah, because that can affect the "external behaviour" (by crashing it
if the pointer is bogus :)

N

[Valgrind-users] Suppressions

From: Alex I. <ale...@in...> - 2003-06-10 19:55:42

R2VudGxlbWVuLA0KDQpJIGFtIGhhdmluZyB0cm91YmxlcyBzdXBwcmVzc2luZyBjZXJ0YWlu
IG1lc3NhZ2VzLCBtYXkgYmUgdGhlIHJlYXNvbiBpcyB0aGF0IHRoZQ0KY2FsbHN0YWNrIGNv
bnRhaW5zIEMrKyBtZW1iZXIgZnVjbnRpb25zIGFuZCBJIGFtIHdyaXRpbmcgdGhlbSBpbiBh
IHdyb25nIHdheSBpbg0KdGhlIHN1cHByZXNzaW9uIGZpbGUgLi4uICBWYWxncmluZCByZWFk
cyB0aGUgc3VwcHJlc3Npb24gZmlsZSBqdXN0IGZpbmUsIGJ1dA0KZXJyb3JzIGFuZCBtZW1v
cnkgbGVha3Mgc3RpbGwgcG9wIHVwLiBCVFcsIEkgYW0gdXNpbmcgMS45LjYuDQoNCkhlcmUg
aXMgYW4gZXJyb3IgdGhhdCBJIGFtIHRyeWluZyB0byBzdXBwcmVzczoNCg0KPT0xNzQyMz09
IFN5c2NhbGwgcGFyYW0gaW9jdGwoQ0RST01SRUFEVE9DRU5UUlkgKGNkdGVfdHJhY2ssIGNo
YXIpKSBjb250YWlucw0KdW5pbml0aWFsaXNlZCBvciB1bmFkZHJlc3NhYmxlIGJ5dGUocykN
Cj09MTc0MjM9PSAgICBhdCAweDQwMzg3RDA0OiBfX0dJX19faW9jdGwgKGluIC9saWIvbGli
Yy0yLjMuMi5zbykNCj09MTc0MjM9PSAgICBieSAweDgwQTgxNDU6IEtJcG1QZXJUaHJlYWRE
YXRhOjpLSXBtUGVyVGhyZWFkRGF0YShpbnQsIGludCwgdm9pZA0KKCopKHZvaWQgKiwgSXBt
Q29uZ2VzdGlvblR5cGUpLCB2b2lkICopICguLi9LSXBtUGVyVGhyZWFkRGF0YS5jYzoyMDgp
DQo9PTE3NDIzPT0gICAgYnkgMHg4MEE2QjUyOiBpcG1Jbml0KHZvaWQpICguLi9jb21tb24v
SXBtUGVyVGhyZWFkRGF0YS5oOjE4MykNCj09MTc0MjM9PSAgICBieSAweDgwNjBDNkE6IGlu
aXRQcm9jZXNzQ29udHJvbChjaGFyIGNvbnN0ICosIHVuc2lnbmVkIGxvbmcsDQpzaG9ydCwg
c2hvcnQpICguLi9jb21tb24vUHJvY2Vzc0NvbnRyb2wuY2M6MjQ5KQ0KPT0xNzQyMz09ICAg
IEFkZHJlc3MgMHgyIGlzIG5vdCBzdGFjaydkLCBtYWxsb2MnZCBvciBmcmVlJ2QNCg0KSGVy
ZSBpcyBhIHN1cHByZXNzaW9uIGVudHJ5Og0KDQp7DQogICAgaW9jdGxfQ0RST01SRUFEVE9D
RU5UUlkvaXBtSW5pdA0KICAgIEFkZHJjaGVjayxNZW1jaGVjazpDb25kDQogICAgZnVuOl9f
R0lfX19pb2N0bA0KICAgIGZ1bjpLSXBtUGVyVGhyZWFkRGF0YTo6S0lwbVBlclRocmVhZERh
dGENCiAgICBmdW46aXBtSW5pdA0KfQ0KDQpIZXJlIGlzIGEgbWVtb3J5IGxlYWsgSSBhbSB0
cnlpbmcgdG8gc3VwcHJlc3M6DQoNCj09MTc0MjM9PSAxMiBieXRlcyBpbiAxIGJsb2NrcyBh
cmUgcG9zc2libHkgbG9zdCBpbiBsb3NzIHJlY29yZCA0IG9mIDQ2DQo9PTE3NDIzPT0gICAg
YXQgMHg0MDE1RTMxMDogbWFsbG9jICh2Z19jbGllbnRmdW5jcy5jOjEwMykNCj09MTc0MjM9
PSAgICBieSAweDgwQkI3NEI6IF9fYnVpbHRpbl9uZXcgKC4uLy4uL2djYy0yLjk1LjMvZ2Nj
L2NwL25ldzEuY2M6NzcpDQo9PTE3NDIzPT0gICAgYnkgMHg4MDYzMzY5OiBQcm9jZXNzb3JD
b25maWdEYjo6QnVpbGRQcm9jZXNzb3JDb250cm9sTmFtZSh2b2lkKQ0KKC4uL2luY2x1ZGUv
TnNEZXN0TGlzdC5oOjE3MykNCj09MTc0MjM9PSAgICBieSAweDgwNjUxOTM6IFByb2Nlc3Nv
ckNvbmZpZ0RiOjpVcGRhdGVTeXN0ZW1OYW1lcyhzaG9ydCkNCiguLi9jb21tb24vUHJvY2Vz
c29yQ29uZmlnRGIuY2M6ODczKQ0KDQpIZXJlIGlzIGEgc3VwcHJlc3Npb24gZW50cnkgKHRo
ZXJlIGFyZSBzaW1pbGFyIGVycm9ycyBmcm9tIHNpbWlsYXIgZnVuY3Rpb25zLA0KaGVuY2Ug
dGhlIHdpbGRjYXJkKQ0KDQp7DQogICAgUHJvY2Vzc29yQ29uZmlnRGIvQnVpbGREYlNlcnZl
ck5hbWUNCiAgICBNZW1jaGVjazpMZWFrDQogICAgZnVuOm1hbGxvYw0KICAgIGZ1bjpfX2J1
aWx0aW5fbmV3DQogICAgZnVuOlByb2Nlc3NvckNvbmZpZ0RiOjpCdWlsZCoNCn0NCg0KUGxl
YXNlLCBsZXQgbWUga25vdyB3aGF0IEkgYW0gbWlzc2luZyBoZXJlISBUaGFua3MgYSBidW5j
aCENCg0KUmVnYXJkcywNCkFsZXgNCg0KLS0NCkFsZXggRy4gSXZlcnNoZW4gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgSW5ldCBUZWNobm9sb2dpZXMsIEluYy4NCk5ldHdvcmsgUHJv
ZHVjdHMgRGVwdC4gICAgICAgICAgICAgICAgICAgICAgMTUwMCBOLiBHcmVlbnZpbGxlIEF2
ZS4NCkluZXQgVGVjaG5vbG9naWVzIEluYy4gICAgICAgICAgICAgICAgICAgICAgUmljaGFy
ZHNvbiwgVFggNzUwODENClBob25lOiArMS00NjktMzMwLTQyOTUgICAgICAgICAgICAgICAg
ICAgICAgVVNBDQoNCiJDb21wdXRlciBnYW1lcyBkb24ndCBhZmZlY3Qga2lkczsgSSBtZWFu
IGlmIFBhYy1NYW4gYWZmZWN0ZWQgdXMgYXMga2lkcywgd2UnZA0KYWxsIGJlIHJ1bm5pbmcg
YXJvdW5kIGluIGRhcmtlbmVkIHJvb21zLCBtdW5jaGluZyBtYWdpYyBwaWxscyBhbmQgbGlz
dGVuaW5nIHRvDQpyZXBldGl0aXZlIGVsZWN0cm9uaWMgbXVzaWMuIiAtLSBLcmlzdGlhbiBX
aWxzb24sIE5pbnRlbmRvLCBJbmMNCg0KDQo=

Re: [Valgrind-users] Suppressions

From: Nicholas N. <nj...@ca...> - 2003-06-10 20:50:28

On Tue, 10 Jun 2003, Alex Ivershen wrote:

> I am having troubles suppressing certain messages, may be the reason is that the
> callstack contains C++ member fucntions and I am writing them in a wrong way in
> the suppression file ...  Valgrind reads the suppression file just fine, but
> errors and memory leaks still pop up. BTW, I am using 1.9.6.

Easy solution:  grab CVS head from Sourceforge, build as per README
instructions, use the --gen-suppressions=yes option.

More details below.

> Here is an error that I am trying to suppress:
>
> ==17423== Syscall param ioctl(CDROMREADTOCENTRY (cdte_track, char)) contains
> uninitialised or unaddressable byte(s)
> ==17423==    at 0x40387D04: __GI___ioctl (in /lib/libc-2.3.2.so)
> ==17423==    by 0x80A8145: KIpmPerThreadData::KIpmPerThreadData(int, int, void
> (*)(void *, IpmCongestionType), void *) (../KIpmPerThreadData.cc:208)
> ==17423==    by 0x80A6B52: ipmInit(void) (../common/IpmPerThreadData.h:183)
> ==17423==    by 0x8060C6A: initProcessControl(char const *, unsigned long,
> short, short) (../common/ProcessControl.cc:249)
> ==17423==    Address 0x2 is not stack'd, malloc'd or free'd
>
> Here is a suppression entry:
>
> {
>     ioctl_CDROMREADTOCENTRY/ipmInit
>     Addrcheck,Memcheck:Cond
>     fun:__GI___ioctl
>     fun:KIpmPerThreadData::KIpmPerThreadData
>     fun:ipmInit
> }

1. C++ names must be _mangled_.  Use --demangle=no to find them out.

2. "Cond" is the wrong type, you want "Syscall" (or something similar, I
can't remember the exact name now).

3. "Syscall" type suppressions (confusingly) needs an extra line before
the first "fun:" line, which I think (off the top of my head) specifies
which argument is the problem.

> Here is a memory leak I am trying to suppress:
>
> ==17423== 12 bytes in 1 blocks are possibly lost in loss record 4 of 46
> ==17423==    at 0x4015E310: malloc (vg_clientfuncs.c:103)
> ==17423==    by 0x80BB74B: __builtin_new (../../gcc-2.95.3/gcc/cp/new1.cc:77)
> ==17423==    by 0x8063369: ProcessorConfigDb::BuildProcessorControlName(void)
> (../include/NsDestList.h:173)
> ==17423==    by 0x8065193: ProcessorConfigDb::UpdateSystemNames(short)
> (../common/ProcessorConfigDb.cc:873)
>
> Here is a suppression entry (there are similar errors from similar functions,
> hence the wildcard)
>
> {
>     ProcessorConfigDb/BuildDbServerName
>     Memcheck:Leak
>     fun:malloc
>     fun:__builtin_new
>     fun:ProcessorConfigDb::Build*
> }

This one's closer, again I think its the mangling that's the problem.

N