|
HP OpenVMS Systemsask the wizard |
|
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.
|