[ Bottom of Page | Previous Page | Next Page | Contents | Index ]

IBM Books

Parallel Environment for AIX 5L V4.1
Operation and Use, Vol 2


SA22-7949-00

Loading the partition with the load subcommand

Before you can debug a parallel program with the pdbx debugger, you need to load your partition. If you specified a program name on the pdbx command, it is already loaded on each task of your partition. If not, you need to load your partition using the load subcommand. pdbx will look for the program in the current directory unless a relative or absolute pathname is specified. The Partition Manager allocates the tasks of your partition when you enter the pdbx command. It does this either by connecting to the Resource Manager or by looking to your host list file. The number of tasks in the partition depends on the value of the MP_PROCS environment variable (or the value specified on the -procs flag) when you enter the pdbx command.

The following pdbx commands are available before the program is loaded on all tasks:

  • alias
  • group
  • help
  • load
  • on
  • quit
  • source
  • tasks
  • unalias

To load the same executable on all tasks of the partition: To load separate executables on the partition:

CHECK
the pdbx command prompt to make sure the command context is on all tasks. The context all is the default when you start the pdbx debugger, so the prompt should read: 
pdbx(all)
If the command context is not set on all tasks, reset it. To do this:

ENTER
on all
Once the command context is on all tasks:

ENTER
load program [program_options]

The specified program is loaded onto all tasks in the partition, and the message "Partition loaded..." displays. The parallel program runs up to the first executable statement and stops.

Note:
The example above has the same effect as putting the program name and options on the command line.

SET
the command context before loading each program. For example, say your partition consists of five tasks numbered 0 through 4. To load a program named program1 on task 0 and a program named program2 on tasks 1 through 4, you would:

ENTER
on 0

The debugger sets the command context on task 0

ENTER
load program1 [program_options]

The debugger loads program1 on task 0.

ENTER
group add groupa 1-4

The debugger creates a task group named groupa consisting of tasks 1 through 4.

ENTER
on groupa

The debugger sets the command context on tasks 1 through 4.

ENTER
load program2 [program_options]

The debugger loads program2 onto tasks 1 through 4, and the message "Partition loaded..." displays. The parallel program runs up to the first executable statement and stops.


Displaying tasks and their states

With the tasks subcommand, you display information about all the tasks in the partition. Task state information is always displayed (see Table 4 for information on task states). If you specify "long" after the command, it also displays the name, ip address, and job manager number associated with the task.

Following is an example of output produced by the tasks and tasks long command. 

pdbx(others) tasks
  0:D     1:D     2:U     3:U     4:R     5:D     6:D     7:R
 
pdbx(others) tasks long
  0:Debug ready   pe04.kgn.ibm.com                 9.117.8.68       -1
  1:Debug ready   pe03.kgn.ibm.com                 9.117.8.39       -1
  2:Unhooked      pe02.kgn.ibm.com                 9.117.11.56      -1
  3:Unhooked      augustus.kgn.ibm.com             9.117.7.77       -1
  4:Running       pe04.kgn.ibm.com                 9.117.8.68       -1
  5:Debug ready   pe03.kgn.ibm.com                 9.117.8.39       -1
  6:Debug ready   pe02.kgn.ibm.com                 9.117.11.56      -1
  7:Running       augustus.kgn.ibm.com             9.117.7.77       -1

Grouping tasks

You can set the context on a group of tasks by first using the context insensitive group subcommand to collect a number of tasks under a group name you choose. None of these tasks need to have been loaded for you to include them in a group. Later, you can set the context on all the tasks in the group by specifying its group name with the on subcommand.

For example, you could use the group subcommand to collect a number of tasks (tasks 0, 1, and 2) as a group named groupa. Then, to set the context on tasks 0, 1, and 2, you would:

ENTER
on groupa

The debugger sets the command context on tasks 0, 1, and 2.

Another use of the group subcommand is to give a name to a task. For example, assume you have a typical master/worker program. Task 0 is the master task, controlling a number of worker tasks. You could create a group named master consisting of just task 0. Then, to set the context on the master task you would:

ENTER
on master

The debugger sets the command context on task 0. Entering on master, therefore, is the same as entering on 0, but would be more meaningful and easier to remember.

The group subcommand has a number of actions. You can use it to:

  • Create a task group, or add tasks to an existing task group
  • Delete a task group, or delete tasks from an existing task group
  • Change the name of an existing task group
  • List the existing task groups, or list the members of a particular task group.

Syntax for group_name

Provide a group name that is no longer than 32 characters which starts with an alphabetic character, and is followed by any alphanumeric character combination.

Syntax for task_list

To indicate a range of tasks, enter the first and last task numbers, separated by a colon or dash. To indicate individual tasks, enter the numbers, separated by a space or comma.

Note:
Group names "all", "none", and "attached" are reserved group names. They are used by the debugger and cannot be used in the group add or group delete commands. However, the group "all" or "attached" can be renamed using the group change command, if it currently exists in the debugging session.

Adding a task to a task group

To add a task to a new or already existing task group, use the add action of the group subcommand. The syntax is:
group add group_name task_list

If the specified group_name already exists, then the debugger adds the tasks in task_list to that group. If the specified group_name does not yet exist, the debugger creates it.
The variable task_list can be: For example, to add the following task(s) to groupa: You would ENTER: The following message displays:
a single task task 6 group add groupa 6 
1 task was added to group
"groupa".
a collection of tasks tasks 6, 8, and 10 group add groupa 6 8 10 
3 tasks were added to group
"groupa".
a range of tasks tasks 6 through 10 group add groupa 6:10 
5 tasks were added to group
"groupa".
a range of tasks tasks 6 through 10 group add groupa 6-10 
5 tasks were added to group
"groupa".

Deleting tasks from a task group

To delete tasks from a task group, use the delete action of the group subcommand. The syntax is:
group delete group_name [task_list]


The variable task_list can be: For example, to delete the following from groupa: You would ENTER: The following message displays:
a single task task 6 group delete groupa 6 
Task: 6 was successfully
deleted from group "groupa".
a collection of tasks task 6, 8, and 10 group delete groupa 6 8 10 
Task: 6 was successfully
deleted from group "groupa".
Task: 8 was successfully
deleted from group "groupa".
Task: 10 was successfully
deleted from group "groupa".
a range of tasks tasks 6 through 10 group delete groupa 6:10 
Task: 6 was successfully
deleted from group "groupa".
Task: 7 was successfully
deleted from group "groupa".
Task: 8 was successfully
deleted from group "groupa".
Task: 9 was successfully
deleted from group "groupa".
Task: 10 was successfully
deleted from group "groupa".
a range of tasks tasks 6 through 8 group delete groupa 6-8 
Task: 6 was successfully
deleted from group "groupa".
Task: 7 was successfully
deleted from group "groupa".
Task: 8 was successfully
deleted from group "groupa".

You can also use the delete action of the group subcommand to delete an entire task group. For example, to delete the task group groupa, you would:

ENTER
group delete groupa

The debugger deletes the task group.

Note:
The pre-defined task group all cannot be deleted.

Changing the name of a task group

To change the name of an existing task group, use the change action of the group subcommand. The syntax is:
group change old_group_name new_group_name

For example, say you want to change the name of task group group1 to groupa. At the pdbx command prompt, you would:

ENTER
group change group1 groupa

The following message displays: 

Group "group1" has been renamed to "groupa".

Listing task groups

To list task groups, their members, and task states use the list action of the group subcommand. The syntax is:
group list [group_name]

You can use the list action to: For example, if you ENTER: Then:
list all the task groups. group list The debugger displays a list of all existing task groups and their members. An example of such a list is shown below. 
pdbx(0) group list
 
allTasks      0:R     1:D     2:D     3:U     4:U     5:D    6:D
              7:D     8:D     9:D    10:D    11:D
evenTasks     0:R     2:D     4:U     6:D     8:D    10:R
oddTasks      1:D     3:U     5:D     7:D     9:D    11:R
master        0:R
workers       1:D     2:D     3:U     4:U     5:D     6:D    7:D
              8:D     9:D    10:R    11:R
list all the members of a single task group group list oddTasks

The debugger displays a list of all the members of task group oddTasks. 

1:D    3:U    5:D    7:D    9:D    11:R

When you list tasks, a single letter will follow each task number. The following table represents the state of affairs on the remote tasks. Common states are "debug ready", where pdbx commands can be issued, and running, where the application has control and is executing.

Table 4. Task States
This letter displayed after a task number: Represents: And indicates that:
N Not loaded the remote task has not yet been loaded with an executable.
S Starting the remote task is being loaded with an executable.
D Debug ready the remote task is stopped and debug commands can be issued.
R Running the remote task is in control and executing the program.
X Exited the remote task has completed execution.
U Unhooked the remote task is executing without debugger intervention.
E Error the remote task is in an unknown state.

When thinking about "task states", consider the perspective of the remote tasks which are each running a copy of dbx. pdbx attempts to coordinate activities in multiple dbx sessions. There are times when this is not possible, typically when one or more tasks have not yet stopped. In this case, from a remote task's dbx perspective, a dbx prompt has not yet been displayed, and your application is still running. Similarly, pdbx will not display a pdbx prompt until all the remote dbx sessions are "debug ready".

Setting command context

You can set the current command context on a specific task or group of tasks so that the debugger directs subsequent context sensitive subcommands to just that task or group. This section also shows how you can temporarily deviate from the current command context you set.

Setting the current command context

When you begin a pdbx session, the default command context is set on all tasks. The pdbx command prompt always indicates the current command context setting, so it initially reads: 

pdbx(all)

Before you can do an on command, you may need to set the thread context to the current running thread, as described in the IBM Parallel Environment for AIX 5L, Hitchhiker's Guide.

Note:
Programs that are not threaded still use threads created by the MPI library.

You can use the on subcommand to set the current command context on one task or a group of tasks. The debugger then directs context sensitive subcommands to just the task(s) specified by group or task name.

You can use the on subcommand to set the current command context before you load your partition. The debugger will only direct context sensitive subcommands to the tasks in the current context. The syntax of the on subcommand is:
on {group_name | task_id}

For example, assume you have a parallel program divided into tasks numbered 0 through 4. To set the current command context on just task 1:

ENTER
on 1

The pdbx command prompt indicates the new setting of the current command context. 

pdbx(1)

You can also use the on subcommand to set the current command context on all the tasks in a specified task group. The task group all - consisting of all tasks - is automatically defined for you and cannot be deleted. To set the command context back on all tasks, you would:

ENTER
on all

The pdbx command prompt shows that the current command context has changed, and that the debugger will now direct context sensitive subcommands to all tasks in the partition. 

pdbx(all)

When you switch context using on context_name, and the new context has at least one task in the "running" state, a message is displayed stating that at least one task is in the "running" state. No pdbx prompt is displayed until all tasks in this context are in the "debug ready" state.

When you switch to a context where all tasks are in the "debug ready" state, the pdbx prompt is displayed immediately, indicating pdbx is ready for a command.

At the pdbx subset prompt, on context_name causes one of the following to happen: either a pdbx prompt is displayed; or a message is displayed indicating the reason why the pdbx prompt will be displayed at a later time. This is generally because one of the tasks is in "running" state. See "Context switch when blocked" for more information.

Temporarily deviating from the current command context

There are times when it is convenient to deviate from the current command context for a single command. You can temporarily deviate from the command context by entering the on subcommand with, on the same line, a context sensitive subcommand. The pdbx prompt will be presented after all of the tasks in the temporary context have completed the command specified. It is possible, using <Ctrl-c> followed by the back or the on command, to issue further pdbx commands in the original context. The syntax is:
on {group_name | task_id} [subcommand]

For example, assume a task group named groupa contains tasks 3 through 5. The current command context is on this group. You want to set a breakpoint at line 99 of task 3 only, and then continue directing commands to all three members of groupa. One way to do this is to enter the three subcommands shown in the following example. This example shows the pdbx command prompt for additional illustration.
pdbx(groupa) on 3
pdbx(3) stop at 99
pdbx(3) on groupa
pdbx(groupa)

It is easier, however, to temporarily deviate from the current command context.
pdbx(groupa) on 3 stop at 99
pdbx(groupa)

The context sensitive stop subcommand is directed to task 3 only, but the current command context is unchanged. The next command entered at the pdbx command prompt is directed to all the tasks in the groupa task group.

At a pdbx prompt, you cannot use on context_name pdbx_command if any of the tasks in the specified context are running.

Context switch when blocked

When a task is blocked (there is no pdbx prompt), you can press <Ctrl-c> to acquire control. This displays the pdbx subset prompt pdbx-subset([group | task]), and provides a subset of pdbx functionality including:

  • Changing the current context
  • Displaying information about groups/tasks
  • Interrupting the application
  • Showing breakpoint/tracepoint status
  • Getting help
  • Exiting the debugger.

You can change the subset of tasks to which context sensitive commands are directed. Also, you can understand more about the current state of the application, and gain control of your application at any time, not just at user-defined breakpoints.

When a pdbx subset prompt is encountered, all input you type at the command line is intercepted by pdbx. All commands are interpreted and operated on by the home node. No data is passed to the remote nodes and standard input (STDIN) is not given to the application. Most commands in the pdbx subset produce information about the application and display the pdbx subset prompt. The exceptions are the halt, back, on, and quit commands. The halt, back, and on commands cause the pdbx prompt to be displayed when all of the tasks in the current context are in "debug ready" state.

The following example shows how the function works. A user is trying to understand the behavior of a program when tasks in the current context hang. This is a four task job with two groups defined called low and high. Low has tasks 0 and 1 while high has tasks 2 and 3. A breakpoint is set after a blocking read in task 2, and somewhere else in task 3. Group high is allowed to continue, and task 2 has a blocking read that will be satisfied by a write from task 0. Since task 0 is not executing, the job is effectively deadlocked and the pdbx prompt will not be displayed. The "effective deadlock" happens because the debugger controls some of the tasks that would otherwise be running. This could be called a debugger induced deadlock.

Using <Ctrl-c> allows the debugger to switch to task 0, then step past the write that satisfies the blocking read in task 2. A subsequent switch to group high shows task 2.

pdbx subset commands

The following table shows some commands that are uniquely available at the pdbx subset prompt, plus other pdbx commands that can be used. Certain commands are not allowed. The available commands keep the same command syntax as the pdbx subcommands (see pdbx subcommands).
This subset command: Is used to: For more information see:
alias [alias_name string] Set or display aliases. Creating, removing, and listing command aliases
back Return to a pdbx prompt. Returning to a pdbx prompt
group <action> [group_name] [task_list] Manipulate groups. The actions are add, change, delete, and list. To indicate a range of tasks, enter the first and last task numbers, separated by a colon or dash. To indicate individual tasks, enter the numbers, separated by a space or comma. Grouping tasks
halt [all] Interrupt all tasks in the current context that are running. If "all" is specified, all tasks, regardless of state, are interrupted. This command always returns to a pdbx prompt. Interrupting tasks
help [subject] Display a list of pdbx commands and topics or help information about them. Accessing help for pdbx subcommands
on <[group | task]> Set the current context for later subcommands. This command always returns to a pdbx prompt. Setting command context
source <cmd_file> Execute subcommands stored in a file.
Note:
The file may contain context sensitive commands.
Reading subcommands from a command file
status [all] Display the trace and stop events within the current context. If "all" is specified, all events, regardless of context, are displayed. Checking event status
tasks [long] Display processes (tasks) and their states. Displaying tasks and their states
quit Exit the pdbx program and kill the application. Exiting pdbx
unalias alias_name Remove a previously defined alias. Creating, removing, and listing command aliases
<Ctrl-c> Has no effect, except to display the following message: 
Typing Ctrl-c from the pdbx subset prompt
has no effect.
Use the halt command to interrupt
the application.
Use the quit command to quit pdbx.
Type help then enter to view brief help of
the commands available.
Context switch when blocked

Returning to a pdbx prompt

The back command causes the pdbx prompt to be displayed, when all the tasks in the current context are in "debug ready" state. You can use the back command if you want the application to continue as it was before <Ctrl-c> was issued. Also, you can use it if during subset mode all of the nodes are checked into debug ready state, and you want to do normal pdbx processing. The back command is only valid in pdbx subset mode.

It is also possible to return to the pdbx prompt using the on and the halt commands.

Controlling program execution

Like the dbx debugger, pdbx lets you set breakpoints and tracepoints to control and monitor program execution. Breakpoints are stopping places in your program. They halt execution, enabling you to then examine the state of the program. Tracepoints are places in the program that, when reached during execution, cause the debugger to print information about the state of the program. An occurrence of either a breakpoint or a tracepoint is called an event.

If you are already familiar with breakpoints and tracepoints as they are used in dbx, be aware that they work somewhat differently in pdbx. The subcommands for setting, checking, and deleting them are similar to their counterparts in dbx, but have been modified for use on parallel programs. These differences stem from the fact that they can now be directed to any number of parallel tasks.

This section describes how to:

  • Set a breakpoint for tasks in the current context using the stop subcommand.
  • Use the halt subcommand to interrupt tasks in the current context.
  • Set a tracepoint for tasks in the current context using the trace subcommand.
  • Use the delete subcommand to remove events for tasks in the current context.
  • Use the status subcommand to display events set for tasks in the current context.

If you are already familiar with the dbx subcommands stop, trace, status, and delete, read the following as a discussion of how these subcommands are changed for pdbx.

The next few pages should act as an introduction to breakpoints and tracepoints if you are unfamiliar with dbx.

Refer to AIX 5L Version 5.1 Commands Reference and AIX 5L Version 5.1 General Programming Concepts: Writing and Debugging Programs for more information on subcommands.

Setting breakpoints

The stop subcommand sets breakpoints for all tasks in the current context. When all tasks reach some breakpoint, execution stops and you can then examine the state of the program using other pdbx or dbx subcommands. These breakpoints can be different on each task.

The syntax of this context sensitive subcommand is:
stop if <condition>


stop at <source_line_number> [if <condition>]


stop in <procedure> [if <condition>]


stop <variable> [if <condition>]


stop <variable> at <source_line_number>
[if <condition>]


stop <variable> in <procedure> [if <condition>]

Specifying stop at <source_line_number> causes the breakpoint to be triggered each time that source line is reached.

Specifying stop in <procedure> causes the breakpoint to be triggered each time the program counter reaches the first executable source line in the procedure (function, subroutine).

Using the <variable> argument to stop causes the breakpoint to be triggered when the contents of the variable changes. This form of breakpoint can be very time consuming. For better results, when possible, further qualify these breakpoints with a source_line or procedure argument.

Specify the <condition> argument using the syntax described by "Specifying expressions".

For example, to set a breakpoint at line 19 for all tasks in the current context, you would:

ENTER
stop at 19

The debugger displays a message reporting the event it has built. The message includes the current context, the event ID associated with your breakpoint, and an interpretation of your command. For example: 

all:[0] stop at "ftoc.c":19

The message reports that a breakpoint was set for the tasks in the task group all, and that the event ID associated with the breakpoint is 0. Notice that the syntax of the interpretation is not exactly the same as the command entered.

Notes:

  1. The pdbx debugger will not set a breakpoint at a line number in a group context if the group members have different current source files. Instead, the following error message will be displayed. 
    ERROR: 0029-2081 Cannot set breakpoint or tracepoint event in
                 different source files.

    If this happens, you can either:

    • change the current context so that the stop subcommand will be directed to tasks with identical source files.
    • set the same source file for all members of the group using the file subcommand.

  2. When specifying a variable name on the stop subcommand in pdbx, it is important to use fully-qualified names as arguments. See Specifying variables on the trace and stop subcommands for more information.

  3. For further details on the stop subcommand, refer to its use on the dbx command as described in AIX 5L Version 5.1 Commands Reference and AIX 5L Version 5.1 General Programming Concepts: Writing and Debugging Programs.

Interrupting tasks

By using the halt command, you interrupt all tasks in the current context that are running. This allows the debugger to gain control of the application at whatever point the running tasks happen to be in the application. To a dbx user, this is the same as using <Ctrl-c>. This command works at the pdbx prompt and at the pdbx subset prompt. If you specify "all" with the halt command, all running tasks, regardless of context, are interrupted.

Note:
At a pdbx prompt, the halt command never has any effect without "all" specified. This is because by definition, at a pdbx prompt, none of the tasks in the current context are in "running" state.

The halt all command at the pdbx prompt affects tasks outside of the current context. Messages at the prompt show the task numbers that are and are not interrupted, but the pdbx prompt returns immediately because the state of the tasks in the current context is unchanged.

When using halt at the pdbx subset prompt, the pdbx prompt occurs when all tasks in the current context have returned to "debug ready" state. If some of the tasks in the current context are running, a message is presented.

Setting tracepoints

The trace subcommand sets tracepoints for all tasks in the current context. When any task reaches a tracepoint, it causes the debugger to print information about the state of the program for that task.

The syntax of this context sensitive subcommand is:
trace [in <procedure>] [if <condition>]


trace <source_line_number> [if <condition>]


trace <procedure> [in <procedure>]
[if <condition>]


trace <variable> [in <procedure>]
[if <condition>]


trace <expression> at <source_line_number>
[if <condition>]

Specifying trace with no arguments causes trace information to be displayed for every source line in your program.

Specifying trace <source_line_number> causes the tracepoint to be triggered each time that source line is reached.

Specifying trace [in <procedure>] causes the tracepoint to be triggered each time your program executes a source line within the procedure (function, subroutine).

Using the <variable> argument to trace causes the tracepoint to be triggered when the contents of the variable changes. This form of tracepoint can be very time consuming. For better results, when possible, further qualify these tracepoints with a source_line_number or procedure argument.

Specify the <condition> argument using the syntax described by "Specifying expressions".

The trace subcommand prints tracing information for a specified procedure, function, sourceline, expression, variable, or condition. For example, to set a tracepoint for the variable foo at line 21 for all tasks in the current context, you would:

ENTER
trace foo at 21

The debugger displays a message reporting the event it has built. The message includes the current context, the event ID associated with your tracepoint, and an interpretation of your command. For example: 

all:[1] trace foo at "bar.c":21

This message reports that the tracepoint was set for the tasks in the task group all, and that the event ID associated with the tracepoint is 1. Notice that the syntax of the interpretation is not exactly the same as the command entered.

Notes:

  1. The pdbx debugger will not set a tracepoint at a line number in a group context if the group members have different current source files. Instead, the following error message will be displayed. 
    ERROR: 0029-2081 Cannot set breakpoint or tracepoint event in
                 different source files.

    If this happens, you can either:

    • change the current context so that the trace subcommand will be directed to tasks with identical source files.
    • set the same source file for all members of the group using the file subcommand.

  2. When specifying a variable name on the trace subcommand in pdbx, it is important to use fully-qualified names as arguments. See Specifying variables on the trace and stop subcommands for more information.

  3. For further detail on the trace subcommand, refer to its use on the dbx command as described in AIX 5L Version 5.1 Commands Reference

Specifying variables on the trace and stop subcommands

When specifying a variable name as an argument on either the stop or trace subcommand, you should use fully-qualified names. This is because, when the stop or trace subcommand is issued, the tasks of your program could be in different functions, and the variable name may resolve differently depending on a task's position.

For example, consider the following SPMD code segment in myfile.c. It is running as two parallel tasks - task 0 and task 1. Task 0 is in func1 at line 4, while task 1 is in func2 at line 9. 

1  int i;
2  func1()
3  {
4      i++;
5  }
6  func2()
7  {
8      int i;
9      i++;
10  }

To display the full qualification of a given variable, you use the which subcommand. For example, to display the full qualification of the variable i if the current context is all:

ENTER
which i

The pdbx debugger displays the full qualification of the variable specified.
0:@myfile.i  (from line 1 of previous example) 
1:@myfile.func2.i  (from line 8 of previous example) 

Because the tasks are at different lines, issuing the following stop command would set a different breakpoint for each task:
stop if (i == 5)

The debugger would display a message reporting the event it has built. 

all:[0] stop if (i == 5)

The i for task 0, however, would represent the global variable (@myfile.i) while the i for task 1 would represent the local variable i declared within func2 (@myfile.func2.i). To specify the global variable i without ambiguity on the stop subcommand, you would:

ENTER
stop if (@myfile.i == 5)

The debugger reports the event it has built. 

all:[0] stop if (@myfile.i == 5)

Deleting pdbx events

The delete subcommand removes events (breakpoints and tracepoints) of the specified pdbx event numbers. To indicate a range of events, enter the first and last event numbers, separated by a colon or dash. To indicate individual events, enter the numbers, separated by a space or comma. You can specify " * ", which deletes all events that were created in the current context. You can also specify "all", which deletes all events regardless of context. The syntax of this context sensitive subcommand is:
delete [event_list | * | all]

The event number is the one associated with the breakpoint or tracepoint. This number is displayed by the stop and trace subcommands when an event is built. Event numbers can also be displayed using the status subcommand. The output of the status command shows the creating context as the first token on the left before the colon.

Event numbers are unique to the context in which they were set, but not globally unique. Keep in mind that, in order to remove an event, the context must be on the appropriate task or task group, except when using the "all" keyword. For example, say the current context is on task 1 and the output of the status subcommand is: 

1:[0] stop in celsius
all:[0] stop at "foo.c":19
all:[1] trace "foo.c":21

To delete all these events, you would do one of the following:

ENTER
on 1

 
delete 0

 
on all

 
delete 0,1

OR
 

ENTER
on 1

 
delete 0

 
on all

 
delete *

OR
 

ENTER
delete all

Checking event status

A list of pdbx events can be displayed using the status subcommand. You can specify "all" after this command to list all events (breakpoints and tracepoints) that have been set in all groups and tasks. This is valid at the pdbx prompt and the pdbx subset prompt.

The following shows examples of status, status all, and incorrect syntax with different breakpoints set on three different groups and two tasks. 

pdbx(all) status
all:[0] stop at "test/vtsample.c":60
 
pdbx(all) status all
1:[0] stop in main
2:[0] stop in mpl_ring
all:[0] stop at "test/vtsample.c":60
evenTasks:[0] stop at "test/vtsample.c":58
oddTasks:[0] stop at "test/vtsample.c":56
 
pdbx(all) status woops
0029-2062 The correct syntax is either 'status' or 'status all'.

Because the status command (without "all" specified) is context sensitive, it will not display status for events outside the context.

Unhooking and hooking tasks

The unhook subcommand lets you unhook a task so that it executes without intervention from the debugger. This subcommand is context sensitive and similar to the detach subcommand in dbx. The important difference is that you can regain control over a task that has been unhooked, while you cannot regain control over one that has been detached. To regain control over an unhooked task, use the hook subcommand. Detach is not supported in pdbx.

To better understand the hook and unhook subcommands, consider the following example. You are debugging a typical master/worker program containing many blocking sends and receives. You have created two task groups. One - named workers - contains all the worker tasks, and the other - named master - contains the master task. You would like to manipulate the master task and let the worker tasks process without debugger interaction. This would save you the bother of switching the command context back and forth between the two task groups.

Since the unhook subcommand is context sensitive, you must first set the context on the workers task group using the on subcommand. At the pdbx command prompt:

ENTER
on workers

The debugger sets the command context on the task group workers.

ENTER
unhook

The debugger unhooks the tasks in the task group workers.

The worker tasks are still indirectly affected by the debugger since they might, for example, have to wait on a blocking receive for a message from the master task. However, they do execute without any direct interaction from the debugger. If you later wish to reestablish control over the tasks in the workers task group, you would, assuming the context is on the workers task group:

ENTER
hook

The debugger hooks any unhooked task in the current command context.

Note:
The hook subcommand is actually an interrupt. When you interrupt a blocking receive, you cause the request to fail. If the program does not deal with an interrupted receive, then data loss may occur.

Examining program data

The following section explains the where, print, and list subcommands for displaying and verifying data.

Viewing program call stacks

The where subcommand displays a list of active procedures and functions.

The syntax of this context sensitive subcommand is:
where

To view the stack trace, issue the

[ Top of Page | Previous Page | Next Page | Contents | Index ]