 |
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>go
ast:: in ast routine <this is the print stmt>
%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.
|
|
|
|
|
