|
From: Yeshurun, M. <mei...@in...> - 2005-10-17 21:56:32
|
I don't understand why that would make a difference. The array is
initialized, it doesn't matter what it contains.
Meir
-----Original Message-----
From: Eric Lauzon [mailto:eri...@ab...]=20
Sent: Monday, October 17, 2005 11:51 PM
To: Yeshurun, Meir
Subject: RE: [Valgrind-users] User error? - Valgrind 3 failing terribly
compared to purify
shouldn't using zeroed memory be less problematic ...?
malloc/memset
new blabla =3D {0};
-elz
=20
> -----Original Message-----
> From: val...@li...=20
> [mailto:val...@li...] On Behalf=20
> Of Yeshurun, Meir
> Sent: 17 octobre 2005 17:21
> To: Brian Crowder
> Cc: val...@li...
> Subject: RE: [Valgrind-users] User error? - Valgrind 3=20
> failing terribly compared to purify
>=20
> It does make a difference.=20
>=20
> If the bytes were merely un-initialized, Valgrind should=20
> never report an error for this program. Since they are not=20
> even valid for reading/writing, Valgrind should report an=20
> error, but only if you specify --partial-loads-ok=3Dno.=20
>=20
> All of this is based on my understanding of what's written in=20
> the Valgrind user manual.
>=20
> Meir
>=20
> -----Original Message-----
> From: Brian Crowder [mailto:cr...@fi...]
> Sent: Monday, October 17, 2005 11:14 PM
> To: Yeshurun, Meir
> Cc: val...@li...
> Subject: Re: [Valgrind-users] User error? - Valgrind 3=20
> failing terribly compared to purify
>=20
>=20
> The bytes are not _only_ uninitalized, however, they are also=20
> beyond the
> end of the allocated data.=20
> (don't know if that makes a difference).
>=20
> -- Brian
>=20
> Yeshurun, Meir wrote:
> > The purpose of this little program was to do exactly that.=20
> My question
> > is why isn't the error suppressed by specifying
> --partial-loads-ok=3Dyes.
> >=20
> > Meir
> >=20
> > -----Original Message-----
> > From: Brian Crowder [mailto:cr...@fi...]=20
> > Sent: Monday, October 17, 2005 11:03 PM
> > To: Yeshurun, Meir
> > Cc: Tom Hughes; val...@li...
> > Subject: Re: [Valgrind-users] User error? - Valgrind 3 failing
> terribly
> > compared to purify
> >=20
> >=20
> > "XXX" is uninitialized memory. Ints are assumed to be 4-byte:
> >=20
> > a =3D { '0', '1', '2', '3', '4', '5', 6', '7', '8', '9',
> 0,
> > XXX, XXX }
> > ((int*)a + 9) =3D { ............................................RRR,
> RRR,
> > RRR, RRR }
> >=20
> > the last two bytes being read in the int dereference are=20
> uninitialized
> > memory.
> >=20
> >=20
> > -- Brian
> >=20
> > Yeshurun, Meir wrote:
> >=20
> >>The following program generates an invalid read even when explicitly
> >>specifying --partial-loads-ok=3Dyes. Am I missing something here?
> >>
> >>#include <cstring>
> >>#include <iostream>
> >>
> >>using namespace std;
> >>
> >>int main()
> >>{
> >> char *a =3D new char[11];
> >> strcpy(a, "0123456789");
> >> int b =3D *(int *)(a + 9); =20
> >>}
> >>
> >>
> >>Thanks,
> >>
> >>Meir
> >>
> >>-----Original Message-----
> >>From: val...@li...
> >>[mailto:val...@li...] On Behalf Of Tom
> >>Hughes
> >>Sent: Monday, October 17, 2005 9:07 PM
> >>To: val...@li...
> >>Subject: RE: [Valgrind-users] User error? - Valgrind 3 failing
> >=20
> > terribly
> >=20
> >>compared to purify
> >>
> >>In message
> >>
> >=20
> >
> <942...@ha...rp.i
> ntel.com>
> >=20
> >> "Yeshurun, Meir" <mei...@in...> wrote:
> >>
> >>
> >>
> >>>There is one issue though: It looks like Valgrind reports partial
> >>
> >>loads
> >>
> >>
> >>>as errors by default. I think this shouldn't be the=20
> default behavior.
> >>
> >>
> >>Actually valgrind doesn't report any loads as errors - it only
> >>reports an error when you use an undefined value in a way that
> >>would effect the result of the program. In other words when a
> >>conditional jump depends on it or you use it as a pointer and
> >>read or write through that pointer.
> >>
> >>It tracks definedness at bit level, so a partial load will mark
> >>some bits as defined and leaves others alone. If you then later
> >>use one of the undefined bits it will complain.
> >>
> >>There are edge cases where it thinks a bit is used when it isn't
> >>really but they are rare.
> >>
> >>I think you need to explain what you mean more fully.
> >>
> >>Tom
> >>
> >=20
> >=20
> >=20
> >=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,=20
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>=20
|