Browse Prior Art Database

Debugging Child Programs

IP.com Disclosure Number: IPCOM000118629D
Original Publication Date: 1997-Apr-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 4 page(s) / 128K

Publishing Venue

IBM

Related People

Corrigan, K: AUTHOR

Abstract

When building software systems, one program is frequently used to spawn another. This operation establishes a parent-child relationship between the two processes.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 44% of the total text.

Debugging Child Programs

      When building software systems, one program is frequently used
to spawn another.  This operation establishes a parent-child
relationship between the two processes.

      This presents difficulties in debugging the child process.  The
requirement is for the child process to be invoked, not by its normal
parent, but by an independent debugger process.  However, independent
invocation of the child by the debugger will generally invalidate the
parent/child relationship.

      The first difficulty encountered is that the pair of
processes may form part of a large suite of programs which have
inter-dependencies.  It is not always possible to stop the parent
process from spawning the child, nor to obtain access to the
necessary code within the parent in order to inject extra code to run
the child under the debugger.  Similarly, the child will often rely
on the presence of its real parent in order to function correctly.

      In the described solution, the parent is allowed to spawn the
child as usual and no changes to the parent code are required.  The
decision to invoke the child in debug mode is made at runtime by an
independent process known as the debug controller.  The parent
process is not aware that the child is subsequently being run under
the debugger.

      Referring to Fig. 1, the debug control process runs
independently and contains a switch to control whether the child is
to run normally or under debug.  When the switch is OFF (or the debug
control process is absent altogether), the subject processes run as a
normal parent/child pair.

      When the debug controller is running and the switch is ON, the
first invocation of the child simply loads its own name, execution
path, and arguments into the shared memory owned by the debug
controller and then sets a trigger to ask for re-invocation under the
debugger. It  then terminates itself.  On receiving the trigger, the
debug controller  starts a new invocation of the child process under
the debugger.  It extracts the program name, execution path, and
arguments from the shared  memory.  It also sets the debug switch OFF
to avoid recursion.

      Once the child is running, it may optionally setup some form of
inter-process communication with its parent.  Whatever form it takes
(e.g., named semaphore or named queue or pipe), the mechanism will
usually build some form of Inter-process Communication (IPC) name
which is made unique by including the Parent Process ID (PID).  Fig.
2 illustrates a typical mechanism for parent/child
inter-communication where both processes share a queue which uses the
parent's process ID in its name.

      However, running the child under a debugger will invalidate the
ability of the child process to establish its parent process ID so
some form of passing the real parent's process ID to the child under
the debugger is required.

      Once again, the shared memory owned by the...