What are some techniques in detecting/debugging memory leak if you don't have trace tools?
+3
A:
- Check out your loops
- Look at where you are allocating variables - do you ever de-allocate them?
- Try and reproduce the leak with a small subset of suspected code.
- MAKE trace tools - you can always log to a file.
lod3n
2009-09-24 19:16:20
Absolutely, check the loops. Almost anything that matters for a leak has to be in code that loops a lot. Huge numbers of programs have leaks in code that executes only once in a while and no one notices or cares.
Kevin Gale
2009-09-25 19:08:12
A leak can be as simple as if (i ==1); str=strdup("foo"); Its not just loops, conditionals weigh in too. In the absence of tools like valgrind the best method is more eyeballs on the code as it evolves. You can't trust your compiler to warn you about everything :)
Tim Post
2009-10-13 17:05:22
+2
A:
Divide and conquer is the best approach. If you have written you code in a systematic way, it should be pretty easy to call subsets of you code. Your best bet is to execute each section of code over and over and see if your memory usage steadily climbs, if not move on to the next section of code.
Also, the wikipedia article on memory leaks has several great links in the references section on detecting memory leaks for different systems (window, macos, linux, etc)
Craig H
2009-09-24 19:21:44
+4
A:
One possibility could be to compile the code and execute it on a system where you can take advantage of built in tools (e.g. libumem on Solaris, or the libc capability on Linux)
philippe
2009-09-25 19:02:17
+1, mcheck() and mprobe() are very good friends of mine on appliances where valgrind simply will not fit :)
Tim Post
2009-10-13 16:56:46
+1
A:
Similar questions on SO:
- Memory leak detectors for C
- Strategies For Tracking Down Memory Leaks When You’ve Done Everything Wrong
In addition to the manual inspection techniques mentioned by others, you should consider a code analysis tool such as valgrind.
Introduction from their site:
Valgrind is an award-winning instrumentation framework for building dynamic analysis tools. There are Valgrind tools that can automatically detect many memory management and threading bugs, and profile your programs in detail. You can also use Valgrind to build new tools.
The Valgrind distribution currently includes six production-quality tools: a memory error detector, two thread error detectors, a cache and branch-prediction profiler, a call-graph generating cache profiler, and a heap profiler. It also includes two experimental tools: a heap/stack/global array overrun detector, and a SimPoint basic block vector generator. It runs on the following platforms: X86/Linux, AMD64/Linux, PPC32/Linux, PPC64/Linux, and X86/Darwin (Mac OS X).
Tim Henigan
2009-09-25 19:15:35
I assume the OP is trying to say he can't use dynamic analysis tools like Valgrind when he says "without trace tools". I don't know of any embedded platforms Valgrind can run on. He might try Splint (http://splint.org/) which is a static analysis tool.
Falaina
2009-09-25 19:44:25
+1
A:
Intercept all functions that allocate and deallocate memory (depending on the platform, the list may look like: malloc, calloc, realloc, strdup, getcwd, free), and in addition to performing what these functions originally do, save information about the calls somewhere, in a dynamically growing global array probably, protected by synchronization primitives for multithreaded programs.
This information may include function name, amount of memory requested, address of the successfully allocated block, stack trace that lets you figure out what the caller was, and so on. In free(), remove corresponding element from the array (if there are none, a wrong pointer is passed to free which is also a error that's good to be detected early). When the program ends, dump the remaining elements of the array - they will be the blocks that leaked. Don't forget about global objects that allocate and deallocate resources before and after main(), respectively. To properly count those resources, you will need to dump the remaining resources after the last global object gets destroyed, so a small hack of your compiler runtime may be necessary
dmityugov
2009-10-09 12:44:21
On a production appliance using a stock libc (that has to be updated from the OS vendor) .. how is this useful? I admire your thinking here, but your proposed solution is not practical. Furthermore, malloc() and free() are very picky from platform to platform. I did not down vote this, but I can not up vote something hacky and non-portable.
Tim Post
2009-10-13 17:00:50
On a production appliance using a stock libc... you can interceptmemory allocation functions with this approach: http://www.gnu.org/software/libtool/manual/libc/Hooks-for-Malloc.html.Already discussed at SO, by the way: http://stackoverflow.com/questions/269659/using-malloc-hooks
dmityugov
2009-10-26 17:07:43
A:
I have used memtrace http://www.fpx.de/fp/Software/MemTrace/ http://sourceforge.net/projects/memtrace/
You may need to call the statistics function to printout if there are any leaks. Best thing is to call this statistics function before and after a module or piece of code gets executed. * Warning * Memtrace is kind enough to allow memory overwrite/double free. It detects these anomalies and gracefully avoids any crash.
subbul
2009-10-13 16:49:39