HP OpenVMS Systems

ask the wizard
Content starts here

Virtual Memory and Access Violation? (ACCVIO)

» close window

The Question is:

Dear Wizard,
How do I know when a page of memory has been loaded and is accessible ?
I am processing large numbers of records using threading architecture, and
 therefore need access to over 1Gb of memory.  I have a 512Mb guaranteed
 working set, with a 1.5Gb quota of un-guaranteed memory.
While looping through this 1Gb of ( non-contiguous ) memory, my application
 causes an ACCVIO and crashes.  This seems to happen around the 537Mb mark, and
 seems to be caused by a thread trying to access memory that has not been paged
 back into the 512Mb y
et.  If I put in printf's around this 537Mb mark, ( in effect slowing the app
 down considerably ), I have no problem.
How can I tell when VMS has finished paging in memory, and that the memory is
 now reliable ?
- Nathan Rozentals, Cape Town, South Africa

The Answer is :

  Please review the common programming errors discussion back
  in topic (1661), and please review the existing discussions
  of debugging access violation (ACCVIO) error.  Please also
  review the introduction to debugging in topic (7552).
  The paging mechansisms are not the proximate cause of this
  error.  (The virtual memory paging mechanisms may well alter
  the timing of the completion of the virtual memory access,
  but paging itself does not and cannot trigger user-mode
  access violations.  What triggers an access violiation is
  an invalid reference -- and not a reference to a page that
  is currently paged out or otherwise in transition.)
  The cause of the application encountering an access violation
  is not related to the size of the working set nor with how
  quickly OpenVMS can load a virtual page from the cache or
  from backing storage.  If the page in virtual memory is
  invalid and must be loaded ("faulted") in, the executing
  thread is placed into a Pagefault Wait (PFW) wait state
  pending the availability of the page.  This page transition
  ("page fault") is entirely and completely transparent to
  application code.  This transition can (and apparently has)
  revealed a latent timing or caching problem, however.
  Put another way, your application code likely contains either
  a memory synchronization bug -- see topics (2681), (6984) and
  (7383) among others -- or it contains any of a host of other
  common programming bugs -- see topic (1661) for a list of some
  of the more common coding bugs.
  Please familiarize yourself with the meaning of the access
  violation (ACCVIO) error, and particularly with the details
  of the error that are provided with the access violation
  signal.  See HELP/MESSAGE ACCVIO, as well as discussions here.
  If you were working with kernel-mode code running at an
  Interrupt Priority Level (IPL) above 2 (above IPL2), then
  and only then you would need to worry about the virtual memory
  paging mechanisms and transitions -- and failures to correctly
  process paging in elevated-IPL kernel-mode code will produce
  PGFIPLHI system bugchecks.   Mechanisms to probe the access
  available to the caller are available for use by such code,
  such as the __PAL_PROBER builtin provided by C.  But the OpenVMS
  Wizard will stress that this and other related builtins and
  mechanisms are not applicable here.  The code involved here is
  very likely the residence of one or more latent bugs.

answer written or last revised on ( 29-MAR-2002 )

» close window