GNU Info

Info Node: (libc.info)Using the Memory Debugger

(libc.info)Using the Memory Debugger


Next: Tips for the Memory Debugger Prev: Tracing malloc Up: Allocation Debugging
Enter node , (file) or (file)node

Example program excerpts
........................

   Even though the tracing functionality does not influence the runtime
behavior of the program it is not a good idea to call `mtrace' in all
programs.  Just imagine that you debug a program using `mtrace' and all
other programs used in the debugging session also trace their `malloc'
calls.  The output file would be the same for all programs and thus is
unusable.  Therefore one should call `mtrace' only if compiled for
debugging.  A program could therefore start like this:

     #include <mcheck.h>
     
     int
     main (int argc, char *argv[])
     {
     #ifdef DEBUGGING
       mtrace ();
     #endif
       ...
     }

   This is all what is needed if you want to trace the calls during the
whole runtime of the program.  Alternatively you can stop the tracing at
any time with a call to `muntrace'.  It is even possible to restart the
tracing again with a new call to `mtrace'.  But this can cause
unreliable results since there may be calls of the functions which are
not called.  Please note that not only the application uses the traced
functions, also libraries (including the C library itself) use these
functions.

   This last point is also why it is no good idea to call `muntrace'
before the program terminated.  The libraries are informed about the
termination of the program only after the program returns from `main'
or calls `exit' and so cannot free the memory they use before this time.

   So the best thing one can do is to call `mtrace' as the very first
function in the program and never call `muntrace'.  So the program
traces almost all uses of the `malloc' functions (except those calls
which are executed by constructors of the program or used libraries).


automatically generated by info2www version 1.2.2.9