  Debugging BASIC MEMMANVIO, Mailboxes, $qio? 
 The Question is:
 
My DEC-BASIC program crashes on a MEMMANVIO.
 
I'm creating a detached process and am communicating with it via an MBX, and it
 works fine as long as everything goes smoothly.
 
However, I'm attempting to ensure the initiating process does not hang, having
 issued a QIOW/READVBLK to the MBX, if the detached process dies for some
 unexpected reason. Immediately before the QIOW I call SETIMR with an AST. But
 regardless of how I calcu
late the time, delta or absolute, with the help of LIB$ routines or without,
 the AST triggers immediately.
 
This occurrance rings vague bells in my memory, and setting the AST to do
 nothing on first invocation returns control to the main program and the QIOW
 executes. SETIMR, despite not being called again, then appears to trigger the
 AST after the correct time
 delay, but immediately crashes on the MEMMANVIO. This continues to be the case
 even if the AST executes only a single PRINT statement.
 
Here's the output using debugger:
 
DBG&gt
ast:: in ast routine &lt;this is the print st
%BAS-F-MEMMANVIO, Memory management violation
 
-BAS-I-USEPC_PSL, at user PC=8028DC40, PSL=0000001B
 
-SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
 address=0000000000000008,
 
PC=FFFFFFFF8028DC40, PS=0000001B
 
-BAS-I-FROFUN, In external function FN_SPAWN
-BAS-I-FROMOD, In module C2
 
break on unhandled exception preceding SHARE$LIBRTL_CODE0+395844
%DEBUG-I-SOURCESCOPE, Source lines not available for 0\%PC
        Displaying source for 9\%PC
 12980:         stat% = sys$qiow (0%, chan%, IO$_READVBLK, iosb,,, q_parms$(0%),
     -: 			  q_buflen%,,,, )
DBG&
 
This is the case whether the AST routine is internal or external, in the same
 .BAS source file or different.
 
Any ideas?
 
thanx
 The Answer is :
 
  Details of the compiler version and the source code may (will) be
  needed -- please contact the support center, as a start.
 
  The OpenVMS Wizard would likely use sys$qio and an AST completion
  routine for the mailbox operation, and not sys$qiow.
 
  The OpenVMS Wizard would further use a mailbox for each process
  and specifically a mailbox where exactly one process reads and
  where zero or more processes might write into it.
 
  Topics discussing various aspects of mailboxes include (1893),
  (5045), (5199), (6497), (6905), (7359), (8746) and others.
 
  The OpenVMS Wizard would generally avoid event flag zero, but
  would substitute EFN$C_ENF -- the Do Not Care event flag.
 
  Topics (7552) and (1661) may be of interest, and discuss debugging
  and common coding errors.  Topic (9027) references the BASIC
  MEMMANVIO error, as well.
 
  The immediate problem appears to involve incorrect arguments to
  an RTL call, either a call made directly within the application
  or through an intermediate library or routine.  This can also
  be caused by stack corruptions, buffer overruns, and similar.
  Again, please review topics including (1661) for detals.
 
  If you need to monitor a process for an exit, use of a lock is far
  more appropriate -- with a unique lock resource name and use of
  blocking and granting ASTs, an entirely servicable and fully
  distributed monitoring scheme can be implemented.  Most
  commonly, a process holds an exclusive lock until it exists,
  and processes wishing to monitor its presence attempt to queue
  incompatible (and usually exclusive) locks.  Should the incompatible
  lock be granted, the target process (or cluster node) has exited.
 
 Answer written or last revised on  29-JAN-2004 
