Image crashing with Access Violation

[#1]

Hi,

Process is crashing with Access Violation. Since the PC value it shows is 0, so I am not able to find out from which part of the code it is throwing this error.
Could you please help me out why the image is crashing and how can i find out where the problem lies.

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

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000010000
0000000000000000
0000000000000000
000000000000001B

Register dump:
R0 = 0000000000000005 R1 = 00000000000100C0 R2 = 0000000000010768
R3 = 000000000001000D R4 = 000000000031000F R5 = 0000000080000C80
R6 = 0000000080001640 R7 = 0000000080001190 R8 = 0000000080003160
R9 = 0000000080003180 R10 = 0000000000040010 R11 = 0000000000010880
R12 = 0000000000A872D0 R13 = 0000000000AA7300 R14 = 0000000000000000
R15 = 000000007AF0C660 R16 = 0000000000011398 R17 = 0000000000010710
R18 = 0000000080000C80 R19 = 0000000080001640 R20 = 0000000080001190
R21 = 0000000080003160 R22 = 0000000000000000 R23 = 0000000000010880
R24 = 000000007BBBFEF0 R25 = 0000000000000002 R26 = 00000000000327A4
R27 = 0000000000000000 R28 = 0000000000036C70 R29 = 000000007AE370D0
SP = 000000007AE370B0 PC = 0000000000000000 PS = 300000000000001B
%SYSTEM-F-ACCVIO, access violation, reason mask=!XB, virtual address=!XH, PC=!XH, PS=!XL
SYSTEM logged out at 24-FEB-2009 10:27:42.97

Regards,
ajaydec

[Volker Halle]

ajaydec,

if you know which image was running, look at the code preceeding VA = 327A4, which most likely is a return address.

Consider to enable a process/image dump in the process before running the image:

$ SET PROC/DUMP
$ RUN ...

The image dump will be written to the current default directory of the process. You can examine the dump with ANAL/PROCESS

Volker.

[#3]

Hi Volker,

Thanks for your reply.

I know which image is running, but it is being executed as a detached process by some other image. So, $ SET PROC/DUMP doesn't creates a dump process.

Also VA=327A4 doesn't gives any information which can help to find the cause of Access Violation.

Could you please tell, what else can I try.

Regards,
ajaydec

[Volker Halle]

ajaydec,

include a SET PROC/DUMP into the DCL procedure, which runs that image or use RUN/DETACH/DUMP

If the image is currently running in a deatched process, you can look at the instruction stream around the address 327A4 to see, if my assumption regarding a valid return address in R26 is true.

$ ANAL/SYS
SDA> SET PROC/ID=
SDA> EXA/INS 327A4-40;50
SDA> EXIT

Just post the instruction stream.

You may need access to the source code and link map (or be able to relink the image with a map) to make further progress.

Volker.

[Hein van den Heuvel]

It looks like the Program Counter tried to start a 0. That could indicsate memory being overwritten (return address on stack) or for example a failed-but-unchecked LIB$FIS call.

Much like Volker suggests a potential return address you might be looking for a the subroutine running into this being called with r argumens (R25) and those arguments being: R16 = 0000000000011398 R17 = 0000000000010710

If you can run the immage /debug, then maye you can find a 'piece of string' or a string descriptor at those addresses to help you understand where to start looking.

If you can not run/debug nor set process/dum then maybe, you can run the image and make it stall (no providing input or set proce/suspend) and use ANAL/SYSTEM to look into it.

It is probaly more fruitful to understand how you got here. Did it ever work? What changed? How long does it run... just string up? If it just starts, then I have often been 'lucky' debugging unknown code by using SET WATCH FILE/CLA=MAJOR. That may indicate how far the the program gets and may even show a file-not-found which was not reported.

The final tool to go for is $SET PROC /SSLOG
The SYSTEM SERVICE LOGGER. Tedious but powerful! Needs a recent OpenVMS.
What version?

Hein.

[Hoff]

There are various ways to track these problems, and you've gotten some reasonable pointers so far, and these are all good for targeting this specific case.

A more general and alternate solution involves fitting the pieces together to make debugging easier; to integrate debugging, and to then use this debugging support and the OpenVMS debugger to more quickly isolate these cases. The integrated debugging could be as simple as print statements, the process dump option as mentioned elsewhere, or could involve dynamic activation of the debugger, or could involve more involved application-specific logging techniques and tools. But (if an application has a history of being unstable) integrating support for debugging can far more quickly stabilize the code than most any other approach. I've done whole presentations and training on this topic.

I'd suggest reading the debugger manual. The debugger is one of the most valuable tools in your arsenal here, and it remains among the best available on any platform; if you're programming on OpenVMS, knowing how to effectively use this tool is invaluable.

I'd then suggest looking at every I/O and every system service, and confirming that these synchronize correctly with EFN and IOSB, and that every one of these calls verifies both the return status and the IOSB status.

Given what I see in that crash, something overwrote a variable (probably a buffer) on the stack with zeros. That's probably a character buffer that was overrun, or could be a late-arriving I/O; a read that completed after the stack frame went out of scope.

Here's a general write-up of diagnosing an ACCVIO crash:

http://64.223.189.234/node/800

Memory management debug and program synchronization discussions:

http://64.223.189.234/node/401
http://64.223.189.234/node/638

[#7]

Hi All,

Thanks a lot to everyone for your valuable time and thoughts.

Problem got resolved when I examine VA=327A4, incorrect function was being called over there.
It could have come as a warning while compiling but I ignored it.

Regards,
ajaydec