Next: , Up: Finding Memory Problems with gnatmem


18.1 Running gnatmem (GDB Mode)

The gnatmem command has the form

        $ gnatmem [-q] [n] [-o file] user_program [program_arg]*
     or
        $ gnatmem [-q] [n] -i file

Gnatmem must be supplied with the executable to examine, followed by its run-time inputs. For example, if a program is executed with the command:

     $ my_program arg1 arg2

then it can be run under gnatmem control using the command:

     $ gnatmem my_program arg1 arg2

The program is transparently executed under the control of the debugger The GNAT Debugger GDB. This does not affect the behavior of the program, except for sensitive real-time programs. When the program has completed execution, gnatmem outputs a report containing general allocation/deallocation information and potential memory leak. For better results, the user program should be compiled with debugging options Switches for gcc.

Here is a simple example of use:

*************** debut cc

     $ gnatmem test_gm
     
     Global information
     ------------------
        Total number of allocations        :  45
        Total number of deallocations      :   6
        Final Water Mark (non freed mem)   :  11.29 Kilobytes
        High Water Mark                    :  11.40 Kilobytes
     
     .
     .
     .
     Allocation Root # 2
     -------------------
      Number of non freed allocations    :  11
      Final Water Mark (non freed mem)   :   1.16 Kilobytes
      High Water Mark                    :   1.27 Kilobytes
      Backtrace                          :
        test_gm.adb:23 test_gm.alloc
     .
     .
     .

The first block of output give general information. In this case, the Ada construct "new" was executed 45 times, and only 6 calls to an unchecked deallocation routine occurred.

Subsequent paragraphs display information on all allocation roots. An allocation root is a specific point in the execution of the program that generates some dynamic allocation, such as a "new" construct. This root is represented by an execution backtrace (or subprogram call stack). By default the backtrace depth for allocations roots is 1, so that a root corresponds exactly to a source location. The backtrace can be made deeper, to make the root more specific.