Re: ACCESS_VIOLATION error (398 Views)
Reply
Regular Advisor
SAMI AHMAD
Posts: 164
Registered: ‎06-19-2008
Message 1 of 5 (468 Views)

ACCESS_VIOLATION error

we are on open VMS 7.1 and an RDB - RALLY legacy application is crashing with the following access violation msg ,  is there a way i can debug and see whats going on ?

 

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=61657243202D2074, PC=61657243202D2074, PS=0000001B

Improperly handled condition, image exit forced.

Signal arguments: Number = 0000000000000005

Name = 000000000000000C

0000000000010000

61657243202D2074

61657243202D2074

000000000000001B

Register dump:

R0 = 000000007AD9B508 R1 = 000000007FF08A60 R2 = 2046414D20646574

R3 = 0000000000020208 R4 = 0000000000000009 R5 = 000000007AD9B850

R6 = 0000000000080BF1 R7 = 000000007FFAC9E0 R8 = 000000007FFAC1F8

R9 = 000000007FFAC400 R10 = 000000007FFAD230 R11 = 000000007FFCE3E0

R12 = 0000000000000000 R13 = FFFFFFFF81120C10 R14 = 0000000000000000

R15 = 000000007AE7DC20 R16 = 00000F0630000003 R17 = 0000000000000000

R18 = 0000000000000000 R19 = 0000000000000000 R20 = 0000000000000000

R21 = 1800000000000B03 R22 = 0000000000000000 R23 = 000000007FF08A60

R24 = FFFFFFFF8100C100 R25 = 0000000000000000 R26 = 61657243202D2074

R27 = 000000000000000C R28 = 0000000000000000 R29 = 2031363139343523

SP = 000000007AD9B5C0 PC = 61657243202D2074 PS = 000000000000001B

%SYSTEM-F-ABORT, abort

HOST_OTO job terminated at 26-FEB-2013 11:28:07.00

Please use plain text.
Valued Contributor
Mike Kier
Posts: 102
Registered: ‎05-18-2003
Message 2 of 5 (462 Views)

Re: ACCESS_VIOLATION error

It is a read access violation (the 00 in the reason mask)

 

It is curious that the virtual address and the PC are the same and both look more like an ASCII string than an address that would be expected - if it is a string it is: (ignoring the enclosing double quote marks)

 

"15: - t"


Does that look familiar in any way?  I wouldn't expect the instruction stream to be jumping to data under normal circumstances from Rally/Rdb, but superficially it appears that way.

Practice Random Acts of VMS Marketing
Please use plain text.
Esteemed Contributor
H.Becker
Posts: 367
Registered: ‎04-09-2009
Message 3 of 5 (453 Views)

Re: ACCESS_VIOLATION error

>>> It is curious that the virtual address and the PC are the same and both look more like an ASCII string than an address that would be expected ...

 

That's a typical pattern when a string overwrites the return address on the stack.  Easy to produce, like in 

$ type f.c
f() {
char x[1];
strcpy (x,"hello world hello world");
}
...
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=6C6C656820646C72, PC=6C6C656820646C72, PS=0000001B
 
Please use plain text.
Honored Contributor
John Gillings
Posts: 2,994
Registered: ‎07-31-2003
Message 4 of 5 (415 Views)

Re: ACCESS_VIOLATION error

Mike,

 

  Sure looks like a clobbered call frame to me. I agree with Hartmut, almost certainly a string overflow. Translating the PC and VA into text, I get: 

 

DBG> set radix hex
DBG> dep r0 = 61657243202D2074
DBG> ex/ascii:8 r0
0\%R0:  't - Crea'

 

Other information from the register dump which may help localise the problem:

 

R2 contains 'ted MAF ' and R29 '#549161 '. I'd guess they all parts of the same string, so you're looking for:

 

t - Created MAF #549161

 

Get yourself a process dump to get more address space to snoop around in.

A crucible of informative mistakes
Please use plain text.
Valued Contributor
Mike Kier
Posts: 102
Registered: ‎05-18-2003
Message 5 of 5 (398 Views)

Re: ACCESS_VIOLATION error

Thanks Hartmut and John!

 

The original poster is Sami.  I'm afraid I don't know enough about Rally to even speculate as to how that could happen.

 

I agree on your analysis of a clobbered call frame, probably due to some sort of overflow - I don't see such things often as I pretty much stick to standard Fortran with fixed length, descriptor-passed strings and use bounds checking on arrays :-)

Practice Random Acts of VMS Marketing
Please use plain text.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation