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 _______________________________________________ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
