|
HP OpenVMS Systemsask the wizard |
|
The Question is: Is there any way to force a system crash when ACCVIO occurs. We have one application which gives access violation on one machine but works fine on other system of identical configuration. We want to analyze the complete system (like resource allocation, any bottlenecks in quota's etc.,) at the moment when it gives access violation. So it would be helpful if we can make system crash immediatey when it encounters a access violation. This crash dump can be analyzed to identify the root cause of the problem. Thx in advance. The Answer is :
A signal handler that uses a sys$cmkrnl call to call a Macro32 or C
routine that requests a BUGCHECK would seem reasonable. Alternatively,
a sys$cmexec call could be used in conjunction with the BUGCHECKFATAL
system parameter, to allow the process or the system to bugcheck either
the process or the system based on the current setting of the system
parameter. The CMEXEC or CMKRNL privilege will be required.
By default, fatal system bugchecks can only be requested from within
inner-mode code; from privileged-mode code.
In C, a routine that calls the bug_check macro looks like this:
#include <ssdef.h>
#include <vms_macros.h>
void CallBugCheck()
{
bug_check( INCONSTATE, FATAL, COLD );
bug_check( CUSTOMER, FATAL, WARM );
return;
}
where the bug_check macro is defined within vms_macros.h.
(The example shown will never call the second bug_check, much less
invoke the return, for obvious reasons.)
To LINK the C code, you will want to use a LINK command involving the
following qualifiers:
$ LINK/SYSEXE/NOSYSLIB OBJECT_MODULE, -
SYS$LIBRARY:VMS$VOLATILE_PRIVATE_INTERFACES -
/INCLUDE=(BUGCHECK_CODES)/LIBRARY
Do note that the C program is linked using /NOSYSLIB, and specifically
links the image this way because you do not and cannot reference any
user-mode C run-time library routines -- or any other user-mode RTL
routines, for that matter -- from within any OpenVMS kernel-mode code.
(The kernel-mode code can also encounter duplicate symbols during the
LINK, if both the user-mode and the kernel-mode C libraries are
erroneously referenced within the same LINK command.)
In Macro32, a routine that calls the BUG_CHECK macro (at an address
labeled 10$) looks like this:
100$: BUG_CHECK INCONSTATE,FATAL
MOVZBL #SS$_NORMAL,R0
RET
The CUSTOMER bugcheck code would likely be the best choice for both this
and for other similar purposes.
The bugcheck codes (BUG$_bugcheck) are resolved at link time (and not via
include definitions), indirectly based on the external symbols created
from the OpenVMS source module BUGCHECK_CODES.REQ (in facility LIB).
A user-written system service can be utilized to allow the code to enter
executive or kernel mode, particularly where the service is installed only
when the bugcheck is to be taken, or is only present on the system when the
bugcheck is to be taken. A user-written system service should NOT be
available except during debugging, otherwise a nefarious user could call
the routine and trigger a system bugcheck.
The user-written system service could be dynamically activated indirectly
via a call to a standard shareable image via lib$find_image_symbol, and
the standard shareable image then calls the user-written system service.
(The use of the standard shareable image is a requirement of the call to
lib$find_image_symbol. It also permits the user-written system service
to be entirely missing from the system or simply not installed, permitting
the creation of a routine that can trap failures when the user-written
system service is called when it is not installed, or not present.)
|