 |
The Question is:
I am trying to do "just in time" debugging for a
detachable process. If a detachable process is
in a LEF state and I want to know where in
the code it is at, is there any to do this
"on the fly"? I seem to remember hearing about
some way to attach the debugger to the process
after it has been running for a long time in
the background. I do not remember specifically
which version of VMS this first became possible,
but it was about three years back.
The Answer is :
One could use a kernel debugger (such as delta or xdelta) for basic
debugging of a "non-debugger-cooperating" application, but this takes
a fair amount of effort and knowledge to accomplish.
For best self-debugging, the application need be compiled and linked with
debug (though it can be set to not invoke the debugger when it first starts
up with an image header patch, or it can start up and pick up a "go" command
via the use of a debugger initialization file, or invoked with /NODEBUG
if a CLI is available in the process), and the image can then be requested
to issue a call to lib$signal() specifying SS$_DEBUG and an ASCIC string
of debugger command(s) -- via interprocess command, via a timer, or other
mechanism. This assumes that DBG$INPUT and DBG$OUTPUT are accessable to
the debugger in the detached process and that they reference an accessable
terminal device, or that the detached process has an accessable affiliated
WSAn: device -- this can be passed in via the sys$error specification.
(The multiprocessor debugger also requires that a CLI be present in the
detached process -- otherwise the full debugger must operate in the same
process context as the application.)
Remote debugging gets rather easier with the new remote multiprocessing
debugger support present in OpenVMS V7.2 -- currently in field test -- as
one can perform collaborative debugging, and one can perform debugging
from clients on remote systems.
One of the best solutions for debugging these sorts of problems in large
or complex applications involves integrated debugging support -- this is
application-specific debugging code incorporated directly into the
application. This can involve the use of a circular buffer in a global
section -- there are examples of code that works with global sections
available in the various example programs posted at the main page of
the Ask The Wizard website.
The application then has integrated calls that deposit indications of
activity into the buffer (or into a file), and a client can read these
indications as required.
For remotely-triggered debugging, the debugger CONNECT command could also
be quite useful, depending on the particular situation.
|
|
|
|
|
