Occasional %SYSTEM-F-ACCVIO error from Java

[P R Stone_1]

I have an occasional failure (approx 1 times out of 5) as follows:

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000000♦
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
DECC$SHR_EV56 0 00000000001C5310 FFFFFFFF81435310
0 FFFFFFFF8007B754 FFFFFFFF8007B754
PTHREAD$RTL 0 000000000006E974 FFFFFFFF81268974
PTHREAD$RTL 0 000000000005717C FFFFFFFF8125117C
PTHREAD$RTL 0 0000000000043940 FFFFFFFF8123D940
0 0000000000000000 0000000000000000
PTHREAD$RTL ? ?
0 FFFFFFFF80337F94 FFFFFFFF80337F94

The Java call is as follows:
$java "-Xmx943718400" -
-cp $java$classpath - "com...." -
... some other parameters


The program used to run perfectly but has failed since we introduced some additional java exec statements.

The program appears to function correctly and produces logging upto the end but fails in the manner given above.

All the exec statements do the same thing
$ SAY = "WRITE SYS$OUTPUT"
$ say "in polytrap = ''p2'"
$polytrap :== $capoly$bin:capoly$trap
$polytrap .....

(This is an ugly way to do it and it is being re-engineered to use java classes throughout)

I have seen threads that indicate a similar error in calling Java from C. Is this a similar failure?

Note: All limits should be set sufficiently high so as not to cause an issue.

[Volker Halle]

P R,

you might want to capture a process dump of this situation. Issue a $ SET PROC/DUMP before starting the JAVA image.

Once this error happens, a process dump will be written to the current default directory. You can have a look at the process dump with: $ ANAL/PROC imagename.DMP

With the process dump, we can at least find out the exact reasons for the ACCVIO. Whether it's possible to find the underlying problem in JAVA is another question.

Volker.