On Sat, 2008-05-17 at 08:36 +0200, Otto Moerbeek wrote:
quoted text
> Yeah, using tools such as valgrind can help a lot, but the danger side
> is that it will cause actions to be taken by people who do not
> understand the code, just to silence valgrind. Since valgrind flags
> the location of the use of uninialized mem, and--of course--not the
> root cause, developers can easily be mislead and apply the wrong fix.
> I think we have a clear demonstration of the danger of using a tool
> without proper understanding of the code here. In addition, the vague
> posts from both sides on openssl-dev mailing lists did not help too. 
> 
> 	-Otto
> 

This might be a good example. I'm working on a CLI which is rapidly
turning into a mini-shell. I'm not using readline, or other commonly
used things to gather input, for the purposes of my own learning and
keeping code portable I've elected to write my own functions.

Every time I make major changes, I run the program through valgrind.
Example results:

==10858==
==10858== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from
1)
==10858== malloc/free: in use at exit: 48 bytes in 5 blocks.
==10858== malloc/free: 12 allocs, 7 frees, 4,182 bytes allocated.
==10858== For counts of detected errors, rerun with: -v
==10858== searching for pointers to 5 not-freed blocks.
==10858== checked 63,724 bytes.
==10858==
==10858== LEAK SUMMARY:
==10858==    definitely lost: 37 bytes in 3 blocks.
==10858==      possibly lost: 0 bytes in 0 blocks.
==10858==    still reachable: 11 bytes in 2 blocks.
==10858==         suppressed: 0 bytes in 0 blocks.
==10858== Use --leak-check=full to see details of leaked memory.

As you can see, my program is in its infancy and not much is allocated.
I have a leak due to some input stuff not freeing things that are
strdup()'ed (I know about this) and I have done a pretty good job of
being defensive so far.

If something I inherit from libc leaks or throws errors, I quickly know
and can explain it. "Its not my program, its stuff I used from xxx
function."

Valgrind is something that is (ideally) used as you go. If you screw up,
it will tell you. It should not be dismissed like trivial compiler
warnings, but it should also not invoke some kind of knee jerk
reaction. 

Its not exactly the world's best auditing tool for someone who is not
used to using it every step of the way. 

Taking something you are unfamiliar with and trying to correct whatever
valgrind complains about is asking for trouble beyond trivial warnings.

What amazes me about this whole mess is that at least 1/3 of the GNU
core utilities issue many complaints but they are ignored.

When you package software, the only reason for squelching the valgrind
results of other people's work is to keep those who install your package
from asking about those warnings.

Like I said in previous posts, shit happens. Nobody needs to be nailed
to a cross for this. The lesson to be learned is:

Q. "Why does your x-y-z package throw so many warnings?"

A. "I am not quite sure, I'm going to ask the developers who wrote it.
Well, I know why its happening, but I can't quite be sure why the code
that causes it is in there."

Cheers,
--Tim

-- 
Monkey + Typewriter = Echoreply ( http://echoreply.us )