|
HP OpenVMS Systemsask the wizard |
|
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.
|