  How to Debug Applications? 
 The Question is:
 
Hi!
 
I know I do not have much information in stack dump, but is there a way to
 debug the C code for this program, and then deposit PC or other register
 values to find out the location where it crashed? If yes, could you please
 show how to do it? It does not r
ecur.
 
Thanks for your time and help,
 
Narendra Patel
 
 The Answer is :
 
  It is clearly long past time for a "how do I debug application code"
  posting, so here it is...
 
  First off, please acquire and read through the OpenVMS manuals --
  reading the manuals is not an admission of defeat, it is how you
  learn about the OpenVMS operating system, how to use it, how to
  program it, and how to debug applications.  The manuals also have
  pointers to available tools, routines, and options.  Put another
  way, PLEASE READ THE AVAILABLE MANUALS.  Thank you!
 
  The specific manuals that will be of interest here are the OpenVMS
  User's Guide, the OpenVMS Programming Concepts Manual, the
  OpenVMS Debugger Manual, and the manual(s) specific to your
  chosen programming lanuage.  You will need general familiarity
  with and reference access to other manuals -- such as the OpenVMS
  LIB Run-Time Library (RTL) manual and the OpenVMS System Services
  Reference Manual.
 
  You will also want to learn the basic troubleshooting technique
  for hardware and software -- this is a technique often known as
  "divide and conquer", or as a real-world version of a recreational
  game known as "Mastermind".  Per this approach, you need to segment
  the environment into two or more smaller units, and to then prove
  (or disprove) the existance of the problem within the smaller unit(s).
 
  Most anything that can be used to divide the environment into smaller
  ranges can be used to (quickly) localize the problem -- with simpler
  applications, dividing up the application into code modules is among
  the most common approaches -- then work through each module, proving
  (or disproving) the existence of the fault.  With larger and more
  complex applications, you can need to create a testing structure
  around the routine(s) being tested, and you can need to incorporate
  debugging into the application -- writing tracking information into
  a debugging log file, for instance, can be useful in finding where
  the failure occurs at run-time.  Additional details are available
  in the OpenVMS Debugger Manual and the OpenVMS Programming Concepts
  Manual.
 
  Next, you will need to specifically learn about the OpenVMS condition
  value format and -- as you learn more advanced techniques on how to
  program and how to debug your code -- and the signal and mechanism
  arrays and the basics of a signal handler.  As a start, the OpenVMS
  condition value describes whether or not the condition indicates
  success (odd) or failure (even), and the severity.  The condition
  value information available also provides details on what other
  information can be included with a signal.  Details on signals and
  signal handlers and condition values are in the OpenVMS Programming
  Concepts Manual.
 
  In this case, an access violation error (ACCVIO) provides you with
  a wealth of information.  It provides you with details of the type
  of access -- whether it was a failed memory read, a failed memory
  write, or some other access -- the failing program counter address,
  the virtual address reference that failed -- and other details.
  Yes, all of these details are readily available within the
  information provided by the access violation!  (See attached.)
 
  To decode the virtual addresses returned by an access violation or
  by another similar OpenVMS display, you need to have created and
  retained a listings  file -- preferably one with machine code
  generation enabled -- and a full link map.  Starting with the virtual
  address reported, use the link map to find the module contributed the
  code that contains the virtual address.  Then use the object listings
  for the component that contributed the code to locate the offset of
  the failing instruction.  (If this information was not maintained,
  working backwards is far more difficult -- you are left to use the
  binary instruction data around the failure to locate the associated
  source code, and this process is far more involved.  Keep the maps
  and listing files around, in other words.)
 
  Rather easier than an approach based on virtual address arithmetic
  and far easier than working backwards from the instruction stream
  is to use integrated debugging -- this inclusion is arguably an
  essential component of any non-trivial application -- and to use the
  OpenVMS Debugger.  The OpenVMS Debugger in particular can be used to
  examine the source code, to examine the stack, and can even be
  programmed to wait patiently for the incidence of a particular value
  within a particular program variable before reporting back to the
  programmer.  The debugger can also be activated from within a
  signal handler, and commands to generate a traceback can be
  generated.  Details on the debugger are in the OpenVMS Debugger
  Manual.
 
  Please learn how to use the debugger.  Additional discussions of
  some of the features and uses of the debugger are available in
  topics (1017), (1314), (1661), (3031) and (4129).
 
  For a list of common programming bugs, please see topic (1661).
  For access violations in particular, there are a large number of
  topics here in Ask The Wizard, including topics (837), (1705),
  (2195), (2223), (3215), (5533), (6065), (6495), (6776), (7110),
  (7551), and others.
 
  For shared memory programming requirements and details useful when
  debugging shared memory, please see topics (2681), (6984) and (7383),
  among others.  The OpenVMS Programming Concepts Manual has details
  on memory synchronization requirements, shared memory interlocking,
  and related topics.
 
  For information on tracking down virtual memory and memory allocation
  bugs in your code -- malloc, free, lib$get_vm, lib$free_vm or otherwise
  commonly trip over corruptions in the memory heap that can (and do)
  result from buffer overruns -- please see topic (3257).
 
  You will also want to move to more current product releases, lest
  you spend your time and effort debugging something that has been
  fixed in the interval since the release shipped.  In this case,
  OpenVMS Alpha V7.1-1H2 was a hardware release, and it is strongly
  recommended that any hardware release be upgraded as soon as a
  subsequent mainline release is available (and appropriately tested
  in your environment).
 
  Please also acquire and install any mandatory ECO kit(s) for the
  version of OpenVMS in use.
 
  C V5.7 is also rather old, and in need of an upgrade -- this C release
  particularly predates a correction to the code generator; a fix needed
  for correct code generation for use on the Alpha 21264 and later Alpha
  microprocessors.
 
  Please also acquire and install any mandatory ECO kit(s) for the
  version of OpenVMS in C -- the C run-time library (RTL) ships with
  OpenVMS, not with C.
 
  And please, please, please, please READ THE MANUALS!  Thank you!
 
  --
 
 ACCVIO,  access violation, reason mask='xx', virtual
          address='location', PC='location', PSL='xxxxxxxx'
 
  Facility:     SYSTEM, System Services
 
  Explanation:  An image attempted to read from or write to a memory location
                that is protected from the current mode. This message
                indicates an exception condition and is followed by a register
                and stack dump to help locate the error. The reason mask is
                a longword whose lowest 5 bits, if set, indicate that the
                instruction caused a length violation (bit 0), referenced the
                process page table (bit 1), attempted a read/modify operation
                (bit 2), was a vector operation on an improperly aligned
                vector element (bit 3), or was a vector instruction reference
                to an I/O space address (bit 4).
 
                This message is also displayed when an attempt has been made
                to make the user stack larger than the user's virtual address
                space permits. For example, the automatic user stack expansion
                algorithm reports an access violation with the following
                two conditions (which should serve as hints that automatic
                expansion has failed):
 
                o The reason mask has the low-order bit set. This indicates a
                  memory reference that is not described in any page table.
 
                o The relatively small P1 address space virtual address is
                  referenced.
 
 
  User Action:  Examine the PC and virtual address displayed in the message.
                The virtual address is often the address to which the access
                attempt was made. However, in the case of vector-related
                access violations and in some processor implementations, the
                reported virtual address may be some other address in the same
                page as that address to which the access was attempted. Check
                the program listing to verify that instruction operands or
                procedure call arguments are correct.
 
                If this message is displayed because of insufficient virtual
                memory for automatic user stack expansion, reduce the user
                stack requirements of the image or increase the virtual
                address space available to the process in which the image
                is executed.
 
 
 Answer written or last revised on  29-MAR-2002 
