Valgrind vs. MAD

[Pavel Roskin <proski gnu org>]

Hello!

Valgrind 1.0.0 has been released.  It's a memory debugger to x86 Linux.  
More details here http://developer.kde.org/~sewardj/

Testing CVS mc with Valgrind in the default mode exhibited 3 bugs:

1) Matching for "shell" rules in ext.c was reading memory before the
filename if it was shorter than the extension being matched against it.
Fixed.

2) Undo buffer in the editor is not initialized.  However, the undo stack
pointer can wrap to the end of the buffer in edit_push_action(), thus
using unitialized data as the base for event compression.  Pending
investigation.

3) There are some messages about incorrect use of getgrnam() in 
vfs/names.c:118.  Possibly bogus.  The warning goes away if mc is compiled 
by gcc-3.1 (it's usually gcc-2.96 from RedHat).

Using additional switches, it's possible to make Valgrind find memory
leaks.  It does it much better than MAD because it knows which pointers
are still used and which have been lost.

Although Valgrind is currently limited to one OS and one architecture, it 
does such a great job, that we should consider removing MAD (memory 
allocation debugger) from the MC sources.

Memory leaks are usually the same on different architectures, and that's 
the only thing MAD can do.

I believe that it's better to direct potential testers to a tool that 
works well, rather than confuse them by keeping an old, less capable MAD.

As for distinguishing between g_malloc() and malloc(), it can be done with
Valgrind by redirecting malloc() and free() to some alternative memory
manager while keeping g_* functions intact.  I don't think it's worth the
trouble to distinguish between g_malloc() and malloc(), as long as we stay
with glib-1.2.

-- 
Regards,
Pavel Roskin