| From: DEC:.REO.REOVTX::HUDSON "[email protected] - UK Software
Partner Engineering 830-4121" 22-MAY-1997 14:22:20.61
To: nm%vbormc::"[email protected]"
CC: HUDSON
Subj: RE: POINT 28903, access violation
Hello Tim Scott
Thank-you for your ASAP question on access violations.
If you do "HELP/MESSAGE ACCVIO", you'll get a detailed description of this
error (I think you may get a couple of descriptions; the one you want is from
the "SYSTEM, System Services" facility).
To summarise, an access violation is an exception that occurs when your program
attempts to touch (read or write) a location in memory which it doesn't have
access to. If your program causes an access violation, you'll typically get a
stack dump like the one you sent me.
But SS$_ACCVIO (value is 12 decimal) is also a status value that some system
services and run-time library routines will return if, for example, you pass in
arguments that are invalid in some way. For example, the system service
$ASSIGN returns SS$_ACCVIO if you don't pass device name in the correct format.
In this case, there hasn't really been an access violation, it's just the
routine's way of telling you that one of the arguments was not OK.
Some programs have code of the form:
stat = some_system_service(arg1,arg2);
if ((stat & 1) != 1) {
lib$signal(stat);
}
In other words, the program checks to see if the status returned was an even
number, and if it was an even number (which by convention under VMS implies
some sort of error), then the program passes the status to LIB$SIGNAL, which
will, in the case of SS$_ACCVIO, also cause a stack-dump similar to the one
you'd see if your program really had access violated. Because this wasn't a
real access violation though, the supplementary arguments in the dump (reason
mask, virtual address, PC, PSL) are just arbitary numbers that happened to be
on the stack when you called LIB$SIGNAL.
For example, the program:
#include <lib$routines.h>
main()
{
lib$signal(12);
}
causes the following dump when run:
%SYSTEM-F-ACCVIO, access violation, reason mask=C0, virtual address=0000001B, PC
=00000001, PS=00000000
%TRACE-F-TRACEBACK, symbolic stack dump follows
Image Name Module Name Routine Name Line Number rel PC abs PC
ACCVIO ACCVIO main 1941 000000C0 000200C0
ACCVIO ACCVIO __main 0 00000064 00020064
So the two most likely explanations for the dump you sent are:
a) An instruction in your program at address 80443A64 attempted to
touch virtual address 00000000. Note that V/A 00000000 is always
inaccessible to programs (not readable, not writeable), partly to
catch programming errors.
In this case, the reason mask of 00 tells us that the attempted
access was a read (bit 2 clear).
b) A system service or library routine returned a status of SS$_ACCVIO,
and something subsequently called LIB$SIGNAL (or LIB$STOP) on that
status.
In the dump you sent, you had:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000, PC
=80443A64, PS=0000001B
The reason mask, VA, PC and PSL look pretty reasonable here, which suggests
that this is a real access violation, rather than a LIB$SIGNAL'd one.
But the address 80443A64 is in system space, which means it's probably not your
own program code that's failing, since that code will be in addresses below
7ffffff.
So this suggests that some VMS code is access violating, and the most likely
reason for that is that you've called (either directly or indirectly) a VMS
routine and passed it arguments which are in some way invalid. Although checks
are done by VMS routines on arguments, those checks can't be exhaustive, and so
sometimes you can make the routines fall over.
So from a debugging point of view, I doubt you're going to be able to get to
the line of code which is access violating, but you should be able to find the
last place in your own code which executed before the access violation
occurred, which hopefully should be a start.
To get the debugger going, you need to compile and link with debug option. For
a C program, this will look like:
$ cc/noopt/debug myprog
$ link/debug myprog
Note that you typically use "/noopt" when compiling with debug, to inhibit
optimization.
If you build the program this way, then when you run it the debugger will start
automatically and you can step through the program, set breakpoints, examine
variables, etc..
I hope this information is useful to you; if anything isn't clear please let me
know
Regards
Nick Hudson
Digital Software Partner Engineering
|
| From: VBORMC::"[email protected]" "Tim Scott" 22-MAY-1997 17:12:57.85
To: hudson <[email protected]>
CC: Tim Scott <[email protected]>
Subj: RE: POINT 28903, access violation
Nick,
thanks for this, it should keep me going for some time.
Unfortunately the customer whose machine is causing the problem has just
assigned their single C compiler licence to another OS user for more urgent
work ...
Is there a debugger command similar to 'where' in dbx ?
It'll be at least a week or so before I can progress this further.
Thank you,
Tim.
----------
From: hudson
To: "[email protected]"
Cc: hudson
Subject: RE: POINT 28903, access violation
Date: 22 May 1997 15:09
Hello Tim Scott
Thank-you for your ASAP question on access violations.
If you do "HELP/MESSAGE ACCVIO", you'll get a detailed description of this
error (I think you may get a couple of descriptions; the one you want is
from
the "SYSTEM, System Services" facility).
To summarise, an access violation is an exception that occurs when your
program
attempts to touch (read or write) a location in memory which it doesn't have
access to. If your program causes an access violation, you'll typically get
a
stack dump like the one you sent me.
But SS$_ACCVIO (value is 12 decimal) is also a status value that some system
services and run-time library routines will return if, for example, you pass
in
arguments that are invalid in some way. For example, the system service
$ASSIGN returns SS$_ACCVIO if you don't pass device name in the correct
format.
In this case, there hasn't really been an access violation, it's just the
routine's way of telling you that one of the arguments was not OK.
Some programs have code of the form:
stat = some_system_service(arg1,arg2);
if ((stat & 1) != 1) {
lib$signal(stat);
}
In other words, the program checks to see if the status returned was an even
number, and if it was an even number (which by convention under VMS implies
some sort of error), then the program passes the status to LIB$SIGNAL, which
will, in the case of SS$_ACCVIO, also cause a stack-dump similar to the one
you'd see if your program really had access violated. Because this wasn't a
real access violation though, the supplementary arguments in the dump
(reason
mask, virtual address, PC, PSL) are just arbitary numbers that happened to
be
on the stack when you called LIB$SIGNAL.
For example, the program:
#include <lib$routines.h>
main()
{
lib$signal(12);
}
causes the following dump when run:
%SYSTEM-F-ACCVIO, access violation, reason mask=C0, virtual
address=0000001B,
PC
=00000001, PS=00000000
%TRACE-F-TRACEBACK, symbolic stack dump follows
Image Name Module Name Routine Name Line Number rel PC abs
PC
ACCVIO ACCVIO main 1941 000000C0
000200C0
ACCVIO ACCVIO __main 0 00000064
00020064
So the two most likely explanations for the dump you sent are:
a) An instruction in your program at address 80443A64 attempted to
touch virtual address 00000000. Note that V/A 00000000 is always
inaccessible to programs (not readable, not writeable), partly to
catch programming errors.
In this case, the reason mask of 00 tells us that the attempted
access was a read (bit 2 clear).
b) A system service or library routine returned a status of
SS$_ACCVIO,
and something subsequently called LIB$SIGNAL (or LIB$STOP) on
that
status.
In the dump you sent, you had:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=00000000,
PC
=80443A64, PS=0000001B
The reason mask, VA, PC and PSL look pretty reasonable here, which suggests
that this is a real access violation, rather than a LIB$SIGNAL'd one.
But the address 80443A64 is in system space, which means it's probably not
your
own program code that's failing, since that code will be in addresses below
7ffffff.
So this suggests that some VMS code is access violating, and the most likely
reason for that is that you've called (either directly or indirectly) a VMS
routine and passed it arguments which are in some way invalid. Although
checks
are done by VMS routines on arguments, those checks can't be exhaustive, and
so
sometimes you can make the routines fall over.
So from a debugging point of view, I doubt you're going to be able to get to
the line of code which is access violating, but you should be able to find
the
last place in your own code which executed before the access violation
occurred, which hopefully should be a start.
To get the debugger going, you need to compile and link with debug option.
For
a C program, this will look like:
$ cc/noopt/debug myprog
$ link/debug myprog
Note that you typically use "/noopt" when compiling with debug, to inhibit
optimization.
If you build the program this way, then when you run it the debugger will
start
automatically and you can step through the program, set breakpoints, examine
variables, etc..
I hope this information is useful to you; if anything isn't clear please let
me
know
Regards
Nick Hudson
Digital Software Partner Engineering
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by
vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id RAA03438 for
<[email protected]>; Thu, 22 May 1997 17:58:53 +0200
% Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by
mail.vbo.dec.com (8.7.3/8.7) with ESMTP id SAA20518 for
<[email protected]>; Thu, 22 May 1997 18:11:47 +0200 (MET DST)
% Received: from swan.fdgroup.co.uk (swan.fdgroup.co.uk [193.129.19.2]) by
server21.digital.fr (8.7.5/8.7) with SMTP id SAA13352 for
<[email protected]>; Thu, 22 May 1997 18:17:30 +0200 (MET DST)
% Received: from dodger by swan.fdgroup.co.uk (AIX 3.2/UCB 5.64/4.03) id
AA31481; Thu, 22 May 1997 17:08:35 +010
% Received: by dodger.fdgroup.co.uk with NT SMTP Gateway ver 31 id
<[email protected]>; Thu, 22 May 97 17:06:29
% From: Tim Scott <[email protected]>
% To: hudson <[email protected]>
% Cc: Tim Scott <[email protected]>
% Subject: RE: POINT 28903, access violation
% Date: Thu, 22 May 97 18:06:00 G
% Message-Id: <[email protected]>
% Encoding: 157 TEXT
% X-Mailer: Microsoft Mail V3.0
|