Java Detached process keeps writing SYSTEM-F-ACCVIO

[Toine_1]

Hi,

I have a detached process (Java written apps) and it gives the following error message (see below) and doesn't stop. I get these errors when using java 1.5 and java 6.

What can I do to get this solved?
I use I64 + VMS 8.3-1H1.
The applications has been running OK for 10 weeks but now it gives daily these errors.

I have found something on the internet regarding : JAVA$FORK_MAILBOX_MESSAGES, JAVA$EXEC_USE_PIPES, and JAVA$FORK_PIPE_STYLE.

But I don't understand how to use this.
Which values should I set in these logicals?

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0000, PC=FFFFFFFF80648D90, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
0 FFFFFFFF80648D90 FFFFFFFF80648D90
0 FFFFFFFF806489D2 FFFFFFFF806489D2
0 FFFFFFFF8066FD92 FFFFFFFF8066FD92
0 FFFFFFFF8055FE72 FFFFFFFF8055FE72
0 FFFFFFFF806069B0 FFFFFFFF806069B0
PTHREAD$RTL THD_VP vpIdle 212985 0000000000000AE2 FFFFFFFF9057ACF2
PTHREAD$RTL THD_SCHED schVpIdlePrim 235906 000000000000C6D2 FFFFFFFF90556672
PTHREAD$RTL THD_SCHED schNullThreadRoutine
235836 0000000000005E62 FFFFFFFF9054FE02
PTHREAD$RTL THD_THREAD thdBase 245139 0000000000005C42 FFFFFFFF90542702
PTHREAD$RTL 0 0000000000053C72 FFFFFFFF9051BC72
PTHREAD$RTL THD_INIT pthread_main 244841 0000000000000492 FFFFFFFF904F8492
0 FFFFFFFF80BAB472 FFFFFFFF80BAB472
DCL 0 000000000006BAF2 000000007AE01AF2
%TRACE-I-END, end of TRACE stack dump
%CXXL-F-TERMINATING, terminate() or unexpected() called
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0000, PC=FFFFFFFF8063F190, PS=0000001B

Improperly handled condition, image exit forced by last chance handler.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000000
0000000000000000
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0000, PC=FFFFFFFF8063F190, PS=0000001B

Improperly handled condition, image exit forced by last chance handler.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000000
0000000000000000
FFFFFFFF8063F190
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0000, PC=FFFFFFFF8063F190, PS=0000001B

Improperly handled condition, image exit forced by last chance handler.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000000
0000000000000000
FFFFFFFF8063F190
000000000000001B
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0000, PC=FFFFFFFF8063F190, PS=0000001B


/Toine

[Rick Retterer · Accepted solution]

Toine,
So you've been running your java application for about 10 weeks now and suddenly it has stopped working and now accivos?

My question is, what what changed on the system lately that has started causing this to happpen? Did you install some patches, make a change to tuning? upgrade any software, make any changes to the sysgen or UAF quotas?

To fix the accvio, I would not start debugging by adding in any logicals into the mix... The logicals you are asking about are for typically tuning application process creation.

By defining the JAVA$FORK_PIPE_STYLE logical to a value of "2", results in the use of a TCPIP Socket rather than using an OpenVMS Mailbox for buffering data between the heap and the SDK application parent process reads.

It is intended to extend the behavior of defining the logical JAVA$EXEC_USE_PIPES, with the optional non-mailbox buffering scheme.

If you want to use logicals like these, trying running the command procedure:
@sys$common:[java$60.com]JAVA$CONFIG_WIZARD.com
and answering the questions that it asks you, and it will create a command procedure that will define the logicals for you. It will create a command procedure for you that you can run before you launch your Java application, or you can dissect the command procedure and add the commands it creates to your own scripts.

As far as the accvio, you may need to break it down into a simpiler configuration to find out what changes you made that suddently caused it to start crashing.

You can also start using things like -Xverbosegc:file:filename.ext, to see what is happening with memory and garbage collection up until it crashes.

I searched the database and I don't see a crash that matches yours..

So, how long does your application run until it crashes?

What are you using for UAF Quotas? Are you using the recommended minimum quotas for Java?

Login to the system using the account that your java application runs under and execute the command procedure:
@sys$common:[java$60.com]java$check_environment.com and see if it points out any anemic resources.

Remember these are minimum recommended resources... You still may need to increase your quota.

How much memory does your application need?
Are you using -Xms -Xmx arguments on your Java command-line?

While your application is running, look at the process, is it page faulting a lot? How many pages of memory is it using?

Let's say you are starting up your application and using -Xms and -Xmx values of 512m. Example:
java -Xms512m -Xmx512m -Xss1024k etc..etc..

Have you provided your process enough WSEXTENT to support a 512mb heap? And, did you increase WSMAX to support a WSEXTENT for a 512mb heap?

Here's the formula that described in the Java Release Notes/User_guide:

(512mb + 512mb % 20) = 614.4 mb
614.4 * 1024 = 629145.6 kb
629145.6 * 1024 = 644245094.4 bytes
644245094.4 / 8192 = 78643.2 (8k pages) Internal -> UAF WSEXTENT value
78643.2 * 16 = 1258291.2 -> "WSMAX" value

You can also use -Xverbosegc:file:filname.ext to capture how much memory and garbage collection is going on up until your application crashes.

Now, all of this is assuming that you have memory allocation issues, it could be that you have something else causing Java to crash, but is something you will probably want to log a call to the support center for, especially if it requires stepping through SDA.

Cheers,
Rick Retterer

[John Gillings]

Toine,

>reason mask=00, virtual address=000000000000
0000, PC=FFFFFFFF80648D90, PS=0000001B

Your ACCVIO tells us it was a memory READ (mask=00), using a null pointer (VA=0) from a system address (PC=FFF...) executing in user mode PS=1B

We also see an "Improperly handled condition" which is an indication that the stack has been trashed.

Without further information, the best guess is one of your routines has been passed a string or array which is shorter than expected. The routine has filled it with nulls, overwriting the stack frame, including a pointer which is then (eventually) passed to a system routine or installed RTL.

The failing code is most likely a victim, so it doesn't help find the culprit. One way to find this kind of bug is to run under DEBUG control, with breakpoints set every so often. Use DBG> SHOW STACK to check the state of the stack at each breakpoint. When you find it corrupted, concentrate on the path from the last good stack.

[H.Becker]

I would check whether the system has the latest patches for exception handling, the C++ libraries and Pthreads. There were problems in this area. But as already said, if this worked before it seems more helpful to find out what changed.

[H.Becker]

>>>
We also see an "Improperly handled condition" which is an indication that the stack has been trashed.

Without further information, the best guess is one of your routines has been passed a string or array which is shorter than expected. The routine has filled it with nulls, overwriting the stack frame, including a pointer which is then (eventually) passed to a system routine or installed RTL.
<<<

The OP uses I64 (+ VMS 8.3-1H1), which uses a register engine to save the registers in a register save area, which is not in/near the user stack. The stack frame itself is described in the unwind information, a piece of the image. So overwriting the stack frame is not that easy. here.

[Dennis Handly]

>H.Becker: which uses a register engine to save the registers in a register save area, which is not near the user stack. So overwriting the stack frame is not that easy.

Right. The RSE stack typically contains the return address. If you have buffers or lots of variables/pointers, they still will be in the user stack, all depending on how aggressive the optimizer is.