[lug] Memory Leak Detection
stimits at comcast.net
Fri Apr 1 13:22:15 MST 2005
Michael Hirsch wrote:
> On Apr 1, 2005 2:29 PM, D. Stimits <stimits at comcast.net> wrote:
>>>After much testing, we can only cause the failure to occur
>>>maybe once every two weeks. In talking it over, we are
>>>wondering if this failure is related to the failures that we
>>>were getting before we expanded the memory. More
>>>specifically, we're wondering if there is a memory leak
>>>somewhere in the code.
>>>My question is, how would we go about doing a test for a
>>>memory leak in this situation?
>>I think specific tools might depend on the language it's written in. For
>>C you could maybe use Valgrind (http://valgrind.org), and there are some
>>similar libs out there for memory debugging.
>>One thing I've noticed about memory failures is that sometimes marginal
>>ram will work for several weeks then fail. Adding more memory and
>>placing it in the lower memory slot can shift the location of the bad
>>memory and reduce how often the problem is seen. Would memtest86 work on
> But it sounds to me like this memory leak might be in the kernel (eth
> driver), not in user space. Does valgrind work there?
There's a good chance his leak is not related to the program in
question. I believe Valgrind works at the library level and intercepts
lib calls and does bookkeeping on them, along with possibly doing some
lint type tasks on the code itself, so it won't help if the app is the
kernel (the kernel doesn't send system calls through glibc or other
libs...it is the system...though I suppose with enough effort individual
drivers could be rearranged to do this...unlikely to be productive). The
memory testing toolkits are designed for individual user space apps.
There are in some cases debug options for some of the kernel drivers,
but unless you know which driver to look at it then it's just a gamble
to start blindly turning on driver debug. On the other hand, there are
some kernel hacking options in the kernel config itself, notably to
compile with frame pointers, page alloc debugging, and check for stack
overflows. Those will make a larger kernel, and slow it, but I've found
that the difference for use of just stack overflow checks and kernel
frame pointers isn't all that noticeable on a common desktop
environment. How it would behave on a PC104 might be more significant.
D. Stimits, stimits AT comcast DOT net
More information about the LUG