Tom,
tom fogal wrote:
> I hope you'll forgive me pushing your reply back to the list. Please
> try to keep the ML in the loop, so that any solutions get archived.
Not a problem...
>
> Brian Wainscott <[EMAIL PROTECTED]> writes:
>> Yeah, I know, which makes tracking these things down a pain. Like I
>> said, this example isn't perfect.
>
> *shrug*, yes. I imagine it is a performance tradeoff -- the branch
> incurred for checking every access isn't worth it, if one can show
> that the invalid code will never cause a problem.
>
> I'm no valgrind developer, but `code speaks louder than words'...
>
>> But I'm still seeing LOTS of these which I didn't see in earlier
>> versions of valgrind (circa. 2 years ago, I don't remember the
>> version number).
>
> Why is this an issue? This code is \emph{wrong}. It doesn't matter
> that valgrind didn't notice until it was passed into printf. If
> earlier versions of valgrind did not report this error, then earlier
> versions of valgrind are buggy.
This code is wrong, of course. But I've got code where I've seen so many
of these reports it is pretty much useless to me. SEVERAL times I have
picked one or two, and tried to track them down, and found them completely
bogus. For example, earlier today, deep inside a program, I got such an
error report. It pointed to a line that read:
ind[ii] = old_ind[ii] = 0;
and ii was the loop variable! There was a nice, clean
"for(ii=0; ii<n; ii++)" up above, and valgrind complained about it.
Now, I'm not claiming the code I'm working on is perfect, by any stretch.
But there are SO many of these that I can't find any that are meaningful.
When I turn off this particular warning.....I get no errors at all, until
it dies in "free()", presumably from heap corruption. So I think there IS
a write to an invalid address somewhere, but valgrind isn't reporting it.
Basically, I wrote to the list to see if anyone else had experienced this
kind of problem, or there was a known issue, or work around, or ????
Valgrind USED to be so helpful to me, quickly tracking down invalid
accesses (and the occasional, but very rare "uninitialized value" error),
but it seems that something happened at some point....
I'd try older versions, but they don't support x86_64. I'm now building my
application on a IA32 machine, in hopes that I can debug it there, maybe
with an old version of valgrind, but I'm not holding out much hope for
that. I'd hate to have to go back and try ElectricFence, but may resort to
that too...
>
> Certainly it would be nicer if memcheck could check all the arguments
> to printf and give out a warning upon the call instead of upon the
> access. That would require valgrind to be a higher level tool than I
> get the impression it is.
>
>> And I DON'T understand why they all complain about 8 byte sizes when
>> all my data is 4 bytes....
>
> Last I checked (1.5[?] years ago), gcc conformed to an x86_64 ABI which
> said arguments are passed in 8-byte locations on the stack. I can
> imagine it also reserves 8 bytes for the return value as well (even if
> the return value is smaller, that is).
Let's not get too caught up in this example! In my real code, I get
complaints on some assignment lines, where as I explained above, I've
tracked the values back and seen no errors. But I believe there IS an
invalid write somewhere, and I'm not seeing it. (At the moment, the only
Invalid write report I get is in "free()" when it would normally segfault,
and my understanding is that this almost certainly means the heap was
corrupted, meaning there was an invalid write somewhere else, but it wasn't
caught by valgrind...)
-- Brian
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
