"In user space there are many open source projects that one can
use to identify memory leaks and corruptions such as electric fence
, its newer fork DUMA , and valgrind . However, for code
running in kernel context these tools are not available.
"When the problems mentioned above end up as a "kernel panic" as
they often do, there is no further ability for the engineer to
inspect the offending code other than to observe the stack trace.
Also in kernel context, a memory leak is persistent: it will remain
existent and most probably keep growing until a reboot, something
that is unacceptable.
"Kernel development allows direct access to the basic components
and resources of the operating system, but debugging is not easy as
the use of a debugger is not handy. One has to either use
additional logging or use advanced techniques such as using kernel
debuggers like kdb  and kgdb  or use kernel patches such
as the one provided by Catalin Marinas, described in ."