4.5 Using the Debugger

Once the debugger's GUI loads, the programmer triggers the program execution by clicking the Start button. When starting by command line, the application is automatically started. The program starts off displaying the user and system entry points as a list of check boxes, freezing at the onset. The user could choose to set breakpoints by clicking on the corresponding entry points and kick off execution by clicking the Continue Button. Figure 2 shows a snapshot of the debugger when a breakpoint is reached. The program freezes when a breakpoint is reached.

Clicking the Freeze button during the execution of the program freezes execution, while Continue button resumes execution. Quit button can be used to abort execution at any point of time. Entities (for instance, array elements) and their contents on any processor can be viewed at any point in time during execution as illustrated in Figure 3.

Figure 3: Freezing program execution and viewing the contents of an array element using the Parallel Debugger

Specific individual processes of the CHARM++ program can be attached to instances of gdb as shown in Figure 4. The programmer chooses which PEs to connect gdb processes to via the checkboxes on the right side. Note! While the program is suspended in gdb for step debugging, the high-level features such as object inspection will not work.

Figure 4: Parallel debugger showing instances of gdb open for the selected processor elements

CHARM++ objects can be examined via the View Entities on PE : Display selector. It allows the user to choose from Charm Objects, Array Elements, Messages in Queue, Readonly Variables, Readonly Messages, Entry Points, Chare Types, Message Types and Mainchares. The right sideselector sets the PE upon which the request for display will be made. The user may then click on the Entity to see the details.

4.5.1 Memory View

The menu option Action  Memory allows the user to display the entire memory layout of a secific processor. An example is shown in figure 5. This layout is colored and the colors have the following meaning:

Figure 5: Main memory view

red

memory allocated by the CHARM++ Runtime System;

blue

memory allocatded directly by the user in its code;

pink

memory used by messages;

orange

memory allocated to a chare element;

black

memory not allocated;

gray

a big jump in memory addresses due to the memory pooling system, it represent a large portion of virtual space not used between two differnt zones of used virtual space address;

yellow

the currently selected memory slot;

Currently it is not possible to change this color association. The bottom part of the view shows the stack trace at the moment when the highlighted (yellow) memory slot was allocated. By left clicking on a particular slot, this slot is fixed in highlight mode. This allows a more accurate inspection of its stack trace when this is large and does not fit the window.

Info Show Statistics will display a small information box like the one in Figure 6.

Figure 6: Information box display memory statistics

A useful tool of this view is the memroy leak search. This is located in the menu Action  Search Leaks. The processor under inspection runs a reacheability test on every memory slot allocated to find if there is a pointer to it. If there is none, the slot is partially colored in green, to indicate its status of leak. The user can the inspect further these slots. Figure 7 shows some leaks being detected.

Figure 7: Memory view after running the Search Leaks tool

If the memory window is kept open while the application is unfrozen and makes progress, the loaded image will become obsolete. To cope with this, the ``Update'' button will refresh the view to the current allocation status. All the leaks that had been already found as such, will still be partially colored in green, while the newly allocated slots will not, even if leaking. To update the leak status, re-run the Search Leaks tool.

Finally, when a specific slot is highlighted, the menu Action  Inspect opens a new window displaying the content of the memory in that slot, as interpreted by the debugger (see next subsection for more details on this).

4.5.2 Inspector framework

Without any code rewriting of the application, CharmDebug is capable of loading a raw area of memory and parse it with a given type name. The result (as shown in Fig. 8), is a browseable tree. The initial type of a memory area is given by its virtual table pointer (CHARM++ objects are virtual and therefore loadbable). In the case of memory slots not containing classes with virtual methods, no display will be possible.

Figure 8: Raw memory parsed and displayed as a tree

When the view is open and is displaying a type, by right clicking on a leaf containing a pointer to another memory location, a popup menu will allow the user to ask for its dereference (shown in Fig. 8). In this case, CharmDebug will load this raw data as well and parse it with the given type name of the pointer. This dereference will be inlined and the leaf will become an internal node of the browse tree.