|
From: Julian S. <js...@ac...> - 2005-10-17 23:07:28
|
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=yes 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
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 = { '0', '1', '2', '3', '4', '5', 6', '7', '8', '9', 0,
> XXX, XXX } ((int*)a + 9) = {
> ............................................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=yes. Am I missing something here?
> >
> > #include <cstring>
> > #include <iostream>
> >
> > using namespace std;
> >
> > int main()
> > {
> > char *a = new char[11];
> > strcpy(a, "0123456789");
> > int b = *(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
|