I would suggest you to use Electric Fence, mpr or checker to handle
problems of Memory Leakage.
ELECTRIC FENCE
**********************
Electric Fence does not find memory leaks, but help to isolate buffer
overruns. As linux, like every modern operating system provides
hardware memory protection to isolate programs from each other.
Electric Fence replaces C libraries malloc() function with a version
that allocates the requested memory and usually allocates a section of
memory immideately after this, which the process is not allowed to
access!
When the process tries to access the memory block pass the allocated
one, kernel traps and halts the process with a segmentation fault! Most
of us might have struggled with this error while working with pointer.
This way Electric Fence manages to get the program killed when it
passes the allocated space.
libefence.a is the library for Electric Fence!
compile the code against Electric Fence library...
$ gcc -ggdb -Wall -o memleak memleak.c -lefence
$ gdb memleak
GDB .....
.....
....
....
(gdb) run
Starting program: /home/achindrab/memleak
Electric Fence... Copyright ...
1: 12345
Program received signal SIGSEGV, segmentation fault.
....
....
(gdb) where
....
..... in main() at memleak.c:18
....
(gdb)
So now we know the error is at line number 18!!!
CHECKER
**************
Checker adds extra code to a program to help find overflows and memory
leaks. Instead of compiling a program with gcc, we can use checkergcc
and the resulting program will debug itself.
The compilation string will be the same:
$ checkergcc -o memleak memleak.c
On executing a program compiled with checkergcc, a long report of
errors is printed ...
The first part of the output tells that we wrote to the part of heap
(memory allocated by malloc()) that was out of all9ocated region. It
tells exactly where the block was allocated - line 11, and which
function caused - strcpy() at line 12.
When we write too many bytes to the local variable, checker gives a
warning that we are writing off the end of stack.
Documentation states, that checker cannot find writes past end of local
buffers, but writes past end of stacks. Thus if more variables have
been allocated after local, checker would not find any problem.
MPR
******
mpr is another tool to play with memory leak problems.
The approach that mpr takes to find the memory leak problems is to map
each malloc( ) with a corresponding free( ) function call. This is a
similar approach, that we take, most often, to detect a memory leak. To
find memory corruption mpr includes a replacement malloc( ) library
from GNU project that includes some support for memory allocation
debugging, which is enabled by calling the mcheck( ) function! We need
to link the application against libmpr.a using command line option:
-lmpr, mcheck( ) will be activated automatically.
Using mcheck( )
~~~~~~~~~~~~
Unlike Electric Fence, mpr's malloc ( ) function adds sequesnce of
bytes, before and after the allocated memory. free( ) looks for those
signatures, and cals abort( ) if they are disturbed...
Running a mpr linked program in gdb shows exactly which region has been
corrupted, but does not pinpoints where the corruption occured. It is
up to the programmer to identify that.
When a program(mpr linked) is run in gdb, it aborts with a signal
abort. on running command 'where', gdb tells the error at free( )
function call, which indicates the problem region.
Over runs on Global variables and local variables, still remains
undetected, can any one help me in that....
A detail explaination on using Debuggers in C is available at:
http://groups-beta.google.com/group/giGABits/ 
