|
From: Yeshurun, M. <mei...@in...> - 2005-10-17 23:21:50
|
Compiling with that flag didn't cause the error not to be reported.
I don't think the problem in this case is related to strcpy, it's
because of the weird read in the last line of the program.
Anyway, isn't there a way to suppress error messages for partially
invalid reads? These error messages are quite frequent, and with some
libraries they appear so often it makes the log file unreadable.
Thanks,
Meir
-----Original Message-----
From: Julian Seward [mailto:js...@ac...]=20
Sent: Tuesday, October 18, 2005 1:09 AM
To: val...@li...
Cc: Brian Crowder; Yeshurun, Meir; Tom Hughes
Subject: Re: [Valgrind-users] User error? - Valgrind 3 failing terribly
compared to purify
What's happening is, gcc or glibc is doing the strcpy using 32-bit
loads/stores and so tramples off the end of the array.
Now ... unfortunately I believe I have confused everybody. Up to
and including 2.4.1, V would allow such loads from array ends without
complaint when --partial-loads-ok=3Dyes applied, which was the default.
But that was always a kludge, which I never liked -- I thought it could
miss genuine bugs like that.
When memcheck was rewritten for the 3.0 line, that hack got dumped.
The rationale was that we would intercept all such str* functions and
substitute our own non-optimised-to-hell versions. And so we do.
And most of the time that works fine.
Unfortunately:
(1) I appear not to have updated the help text, removed the flag
handler, or updated the manual. That's really bad .. sorry.
(2) The intercept trick is defeated if gcc inlines strcpy/strcmp,
which in your example I believe it will do. What happens if=20
you try again with -mno-inline-all-stringops for gcc?
J
On Monday 17 October 2005 22:02, Brian Crowder wrote:
> "XXX" is uninitialized memory. Ints are assumed to be 4-byte:
>
> a =3D { '0', '1', '2', '3', '4', '5', 6', '7', '8', '9',
0,
> XXX, XXX } ((int*)a + 9) =3D {
> ............................................RRR, RRR, RRR, RRR }
>
> the last two bytes being read in the int dereference are uninitialized
> memory.
>
>
> -- Brian
>
> Yeshurun, Meir wrote:
> > 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);
> > }
> >
> >
> > 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
terribly
> > compared to purify
> >
> > In message
> >
<942...@ha...>
> >
> > "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 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
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|