GNU Info

Info Node: (libc.info)Tips for the Memory Debugger

(libc.info)Tips for the Memory Debugger


Next: Interpreting the traces Prev: Using the Memory Debugger Up: Allocation Debugging
Enter node , (file) or (file)node

Some more or less clever ideas
..............................

   You know the situation.  The program is prepared for debugging and in
all debugging sessions it runs well.  But once it is started without
debugging the error shows up.  A typical example is a memory leak that
becomes visible only when we turn off the debugging.  If you foresee
such situations you can still win.  Simply use something equivalent to
the following little program:

     #include <mcheck.h>
     #include <signal.h>
     
     static void
     enable (int sig)
     {
       mtrace ();
       signal (SIGUSR1, enable);
     }
     
     static void
     disable (int sig)
     {
       muntrace ();
       signal (SIGUSR2, disable);
     }
     
     int
     main (int argc, char *argv[])
     {
       ...
     
       signal (SIGUSR1, enable);
       signal (SIGUSR2, disable);
     
       ...
     }

   I.e., the user can start the memory debugger any time s/he wants if
the program was started with `MALLOC_TRACE' set in the environment.
The output will of course not show the allocations which happened before
the first signal but if there is a memory leak this will show up
nevertheless.


automatically generated by info2www version 1.2.2.9