HP OpenVMS Systems

dynamic invocation of the debugger?

» close window

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.
 

  

     

     
answer written or last revised on ( 23-JAN-2002 )
     
» close window