HP OpenVMS Systems

ask the wizard
Content starts here

Application Access Violation (ACCVIO)?

» close window

The Question is:

We have a process "msched" (written in C) that is using an oracle VMS client
 (pre compiler) to generate Oracle SQL code to interface with the dB.
The process runs without incident for 15 days (approximately 400,000 reads),
 then exits with the following error:
%DEBUGBOOT-W-EXQUOTA, process quota exceeded
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000000B
  Improperly handled condition, image exit forced.
    Signal arguments:   Number = 0000000000000005
                        Name   = 000000000000000C
    Register dump:
    R0  = FFFFFFFFFFFFFFFF  R1  = 000000007B90C1F8  R2  = 00000000001D80E0
    R3  = 0000000000000810  R4  = 0000000000000000  R5  = 0000000000000003
    R6  = 000000000095E3C0  R7  = 00000000008FDDE8  R8  = 0000000000000000
    R9  = 000000000095E3C0  R10 = 00000000008FDDE8  R11 = 0000000000000000
    R12 = 0000000000969558  R13 = 00000000009694D0  R14 = 0000000000000000
    R15 = 000000007B04A028  R16 = 0000000000AF806E  R17 = 0000000000000810
    R18 = 0000000000000000  R19 = 0000000000000001  R20 = 000000000000080C
    R21 = 000000000035BEB0  R22 = 0000000000000001  R23 = 000000000035BE80
    R24 = 000000000035BE88  R25 = 0000000000000003  R26 = 00000000006E35D0
    R27 = FFFFFFFF82AC6BA0  R28 = 000000007BCCCA10  R29 = 000000007B049350
    SP  = 000000007B049350  PC  = FFFFFFFF808E5BE0  PS  = 100000000000001B
We believe the error is a pointer problem wihtin the Oracle generated code.  Do
 you have any suggestions how to prove this.

The Answer is :

  The OpenVMS Wizard would tend to recommend confirmation of the particular
  belief -- it is often easier to work forward and follow the steps involved
  in debugging -- topic (7552) and such -- and localize the problem first.
  Guesses are useful when correct, but guesses that cannot be verified or
  that prove inaccurate can serve to delay problem resolution.
  Please do realize that an application can run for years with a latent
  bug -- latent bugs can be timing issues, pool corruptions, quota leaks,
  or any number of other problems.  Topic (1661) has an introduction to
  some of the more common application coding problems, and pointers to
  many of the related discussions.
  The immediate failure is an apparent access violation, though debugging
  this failure will require monitoring virtual address space usage (leaks),
  process quotas, and pool coherency -- the usual steps involved in
  debugging an application.
  Related topics include (2681) and (6099), as well as (1661) cited earlier.
  Also see (2624) and (2630).   Also the ACCVIO topics: (837), (1705),
  (2195), (2223), (3215), (5533), (6065), (6495), (6776), (7551), etc.
  Also please see the ASTs, threads, reentrancy, and shared memory topics:
  (2681), (4647), (6099), and (6984).   And debugging and traceback topics
  such as (4129) and (7552) will also be of interest.  For virtual memory
  debugging and for typical steps in resolving memory heap corruptions --
  for an introduction to fenceposts -- please see (3257).
  Please do apply the required mandatory ECO kits for OpenVMS and core
  layered products, as well as current versions and ECOs for relevent
  layered products, and please also confirm current versions and ECOs
  with the applicable third-party product vendors' support organizations.

answer written or last revised on ( 20-JAN-2004 )

» close window