From: Jeff D. <jd...@ad...> - 2007-08-15 15:53:31
|
On Fri, Aug 10, 2007 at 04:38:09PM -0700, Dan Kegel wrote: > Many people (myself included) have wished that > Valgrind could run UML properly. And me. > But what problems, exactly, should valgrind be able to detect? Pretty much everything it can detect on anything else. > For instance, it would be unreasonable to > expect valgrinding UML to be able to find > memory leaks in programs running under UML. > (Don't laugh, somebody asked that very thing > of valgrind and wine.) Yup, it would be restricted to the kernel. valgrinding userspace is a matter of running valgrind in userspace. BTW, I wonder if you could replace the ELF loader with something that runs valgrind if you want to analyze the whole system. > Naively, I would expect valgrinding UML to > be able to find wild pointer references, > references to freed memory, and > real uses of uninitialized variables > inside kernel code. But I'm not completely > sure that I know enough to define those terms > more concretely. (Perhaps kernel memory allocation > is complicated enough that it's not simple > to define them.) The kernel would need some annotations for these (esp memory leaks and the like) to work correctly. There is a mechanism for the analyzee to communicate with valgrind with certain noop instructions. These can be used to (IIRC) change the state of a buffer, i.e. from unallocated to allocated and back. You'd do this on the boundaries of the memory allocators, and valgrind should then be fine with finding leaks, use-after-free bugsm, and the like. > It would probably be useful to put together an > example kernel module that made a bunch of > mistakes that might reasonably be detected > by valgrind. I'll probably do that sometime soon, > but thought I'd bring up the idea in case anybody > else had thought about it already. That shouldn't be necessary. If valgrind ever ran on UML, it would turn up some legitimate, but harmless things, like uninitialized characters being send over pipes to wake up another thread. Jeff -- Work email - jdike at linux dot intel dot com |