HP OpenVMS Systems

Debugging dynamically activated shareable images

» close window

The Question is:

 
(This is similar but not really the same as another question
asked by someone else some time ago.)
 
I have an image X which uses LIB$FIND_IMAGE_SYMBOL to
dynamically load shareable image Y.  X runs in a
detached or batch process.  At run-time,
code in Y suffers an access violation.  If I enable
process dumps, I get a good dump but the debugger
information is not available for Y when I
use analyze/process on the process dump, even though
Y has been dynamically loaded before the accvio
occurs.  So, I can't do much to diagnose the problem
after-the-fact using the dump.
 
Is there some way I can "coach" the debugger or
process dump analyzer to know about Y's symbolic
debugger info?
 
I'd like to avoid having to relink X to statically
link in Y, which would also take care of this.
 
Thanks.
 

The Answer is :

 
  First, the Wizard will assume that the shareable image has been compiled
  and linked with /DEBUG enabled, and that the debugger SET IMAGE command
  was used to select the target image.  And that this sequence does not work.
 
  The process dump logic does not copy out information related to shareable
  images that have been dynamically activated on many (all?) OpenVMS versions.
 
  The Wizard would suggest using the debugger in the detached process, using
  the debugger directly rather than on the process dump file.  The process
  can use a signal of SS$_DEBUG to enable and load the debugger dynamically,
  or can use a script of debugger commands to log the most interesting parts
  of the failing code, or other similar debugger sequences.
 
  Redirection of the debugger input and output to an accessable interactive
  device can be achieved by associating a WSA0: workstation device with the
  detached process, or by using the DBG$* logical names (in the process, job,
  or group logical name table).

  

     

     
answer written or last revised on ( 20-OCT-1998 )
     
» close window