- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Access violation where VA = PC
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-14-2007 12:32 AM
тАО02-14-2007 12:32 AM
Access violation where VA = PC
The reason code is 00 (data read).
What is a bit odd is that the virtual address is the same as the PC.
I've tried to reproduce this condition (by hacking function pointers and stack stomping) but so far failed - the PC is always different from the virtual address.
Any idea how this situation might come about?
i.e. the sort of bugs to look for.
Details below.
%SYSTEM-F-ACCVIO, access violation,
reason mask=00
virtual address=005D99A8005D98C0,
PC=005D99A8005D98C0
PS=0000001B
Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000010000
005D99A8005D98C0
005D99A8005D98C0
000000000000001B
I've asked for the MAP file which may give some more clues.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-14-2007 01:32 AM
тАО02-14-2007 01:32 AM
Re: Access violation where VA = PC
Like a RETURN address on a stack being corrupted.
Or a badly passed AST address?
Is this new code? Language? recent modificarrtions on working code? 'Nothing changed' ?
>> What is a bit odd is that the virtual address is the same as the PC.
Well, that PV would be a bad virtual address in all likelyhood no?
The real target address is probably 0x5D98C0
Check that address (debugger? MAP?) what is expected there for clues.
hth,
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-14-2007 01:47 AM
тАО02-14-2007 01:47 AM
Re: Access violation where VA = PC
We are asking the customer to enable crash dumps in case it happens again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-14-2007 02:00 AM
тАО02-14-2007 02:00 AM
Re: Access violation where VA = PC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-14-2007 03:38 AM
тАО02-14-2007 03:38 AM
Re: Access violation where VA = PC
Consider this:
$ mcr sys$login:tmp -11 -12
%SYSTEM-F-ACCVIO, access violation,
reason mask=00,
virtual address=000201B8000201B8, PC=000201B8000201B8, PS=0000001B
Code?
#include
b (int i, int j, int *x)
{
x[i] = x[j];
}
a (int i, int j, int *x)
{
b(i, j, x);
}
main(int argc,char *argv[])
{
int i,j,x[100];
i = atoi(argv[1]);
j = atoi(argv[2]);
a(i,j,x);
}
Cheers,
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-14-2007 06:33 AM
тАО02-14-2007 06:33 AM
Re: Access violation where VA = PC
Do post the full stack trace.
If that's the full stack trace, then you'll probably end up adding at least debugging information and potentially instrumenting the code. Unfortunately, adding debug or instrumentation can perturb the bug, and might well cause it to enter remission.
Stephen Hoffman
HoffmanLabs
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-14-2007 12:31 PM
тАО02-14-2007 12:31 PM
Re: Access violation where VA = PC
I'd be enabling PROCESS dumps - SET PROCESS/DUMP
You don't mention a version - make sure you're at V7.3-2 at least. Use DEBUG or SDA to analyse the resulting dump.
VA=PC is a fairly specific footprint. Since there are few modern language constructs which allow jumping to an arbitrary address, the most likely cause is loading a PC from the stack. So, you're looking for something that overwrites the return address in a call frame. The "improperly handled condition" suggests that other pieces of the call frame have also been corrupted.
The biggest problem with tracking these type of errors down is the "distance" between cause and effect. The corruption could be caused by the first executable line in the routine, but not actually seen until you attempt to exit. In DEBUG you can step a few lines, then check the integrity of the stack with SHOW CALL. From within a program, you can do something similar with LIB$GET_INVO* routines (potentially non-destructive). Another option would be to declare a condition handler at top level which can SS$_CONTINUE some specific condition. You can then check the integrity of the stack by LIB$SIGNALling that condition. If it's good, you continue, if not you'll get an improperly handled condition.
If your magic number "005D99A8005D98C0" is always the same, have a look at the 32 bit addresses in a live process from SDA. I'd guess they're pointers within a data structure which has a size mismatch between a the caller (too small) and called routine.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-14-2007 07:08 PM
тАО02-14-2007 07:08 PM
Re: Access violation where VA = PC
First, a question. Does enabling DEBUG and using the debugger preserve the problem?
If so, then you can use the more advanced facilities in the DEBUGGER to isolate the region in the program where the stack is being corrupted. Most importantly, is there a test case that consistently produces the failure, and does it still fail when the DEBUGGER is enabled.
In nearly 30 years of debugging programs under OpenVMS, for myself and clients, I have had a few cases where stack corruption bugs manifested themselves at great distances from the actual corruption. Tracking them down can be difficult. Some of them have even appeared/disappeared depending on the presence of the DEBUGGER, which can be particularly aggravating.
-Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-14-2007 09:59 PM
тАО02-14-2007 09:59 PM
Re: Access violation where VA = PC
This *may* contain the address the supposed JSR should have returned to.
If you have what looks like a valid address there, check to see if it is code, and if so, is that address preceded by a JSR R26(R26) ?
If all this works out, you should be able to work out where your bogus VA came from.
Sebastian, should you wish to do so, you are welcome to call me, I think I gave you my card at one of the London seminars.
JT:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-18-2007 11:42 PM
тАО02-18-2007 11:42 PM
Re: Access violation where VA = PC
I've suggested that the customer enable process dumps for the application. It is a batch process so that's easy to do. Using DEBUG on the live process is not an option.
Hein: I tried your crash program on VMS 7.3-1 (Compaq C V6.4-008) and it does not crash using -11 -12 as parameters - nor any others I tried. (I do get an access violation if the parameters are omitted). Also fails to crash using Compaq C V6.5-001 on OpenVMS Alpha V7.3-2.
Not yet had a chance to look at the other suggestions.