[lug] Memory Leak Detection

[D. Stimits]

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
>>a PC104?
> 
> 
> 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