Re: Valgrind

Thanks! Truly a great toool for hunting memory misuses and it
immediately spotted two reuse-after-free issues in Squid-2.5 (helper
shutdown, aufs swapout of small files). Beats the old ElectricFence I
have been using by a huge margin. Valgrind traps everything EF is
capable of, and at once in one run without having to be reconfigured
to trap different types of errors, and a lot more, and allowing the
program to continue even in case of errors making diagnosing and
isolation of the error source easier and gives almost perfect
feedback on memory errors..

But not yet as good as memproof for hunting memory leaks.. the "no
pointer reference" algorithms seems to be there, but it seems to lack
a method to trigger the leak detection while the program is running
and some of the intuitivity of memproof in finding leaks (sorting,
memory profile, ..)

Needed to fiddle a little to make it run on my RH7.3 system, but not
much..

  - Had to comment out the GLIBC_2.2.3 version definition in
vg_libpthread.vs or else the dynamic linker failed to find the
__pthread_clock_gettime GLIBC_PRIVATE versioned symbols..

  - One need to remember to set LD_LIBRARY_PATH to /usr/lib/debug/ to
get proper symbol information from libraries... (RH7.3 defaults to
stripped libraries).

In all it seems to be a very good framework, relatively efficient
approach, and relatively simple to extend with additional
verifications of various C functions as needed (not only memory)
making a very promising future.

Regards
Henrik

On Monday 29 July 2002 19.25, Florin Andrei wrote:
> http://developer.kde.org/~sewardj/
>
> Valgrind is a GPL'd tool to help you find memory-management
> problems in your programs. When a program is run under Valgrind's
> supervision, all reads and writes of memory are checked, and calls
> to
> malloc/new/free/delete are intercepted. As a result, Valgrind can
> detect problems such as:
>
> * Use of uninitialised memory
> * Reading/writing memory after it has been free'd
> * Reading/writing off the end of malloc'd blocks
> * Reading/writing inappropriate areas on the stack
> * Memory leaks -- where pointers to malloc'd blocks are lost
> forever * Passing of uninitialised and/or unaddressible memory to
> system calls
> * Mismatched use of malloc/new/new [] vs free/delete/delete []
> * Some misuses of the POSIX pthreads API
Received on Sun Aug 11 2002 - 17:41:26 MDT