V5.4 ECO4 IMAP Server %SYSTEM-F-ACCVIO

[Mark E. Levy]

Help! The IMAP server on my AlphaStation 1200 is crashing and restarting with alarming frequency. I've tried expanding the process quotas to no avail. Any hints or pointers are appreciated. The traceback is as follows:

%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00000000008DC000, PC=FFFFFFFF8083008C, PS=0000001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000004
00000000008DC000
FFFFFFFF8083008C
000000000000001B

Register dump:
R0 = 00000000008DBDC0 R1 = 0000000000746313 R2 = 000000007BFD5D10
R3 = 0000000000663510 R4 = 0000000000585AE8 R5 = 0000000000004401
R6 = 0000000000000001 R7 = 0000000000000000 R8 = 00000000656D5FFA
R9 = 0000000000000006 R10 = 0000000000000005 R11 = 0000000000000000
R12 = 0000000000663EA8 R13 = 0000000000000009 R14 = 0000000000000000
R15 = 0000000000000002 R16 = 00000000008DC000 R17 = 0000000000000000
R18 = 0000696C0065CFC8 R19 = 0000000000000000 R20 = 0000000000810FE0
R21 = 000000007B6049D0 R22 = 0000000000000001 R23 = 000000007B6047C8
R24 = 000000000065CFC8 R25 = 00000000008DBDC0 R26 = FFFFFFFF80830050
R27 = 000000007B5C7340 R28 = 0000000000000000 R29 = 0000000000810D40
SP = 0000000000810D40 PC = FFFFFFFF8083008C PS = 000000000000001B

[Mark E. Levy]

Neglected to mention: I'm running V7.3-1.

TIA

[Steven Schweda]

ECO 5? You could get lucky.

[Ana M. García Olivencia]

Mark.

Have these accvios suddenly appeared on your system or have they begun to appear after any TCPIP ECO installation or change in workload?.

We are working with v7.3-2 and after installing TCP/IP ECO5 (that included a new release of TCPIP$IMAP_SERVER.EXE), a lot of accvios from TCPIP$IMAP were generated.

We opened a call to HP and Engineering told us to restore the original image from V7.3-2. But this os version is not the same as yours.

Other suggestions:

- Accounting info of the tcpip$imap processes.

- Check quotas consumption online.

- Check if PTHREAD_DUMP.LOG files have been generated.

- To enable "Server-Trace=True" in the IMAP configuration file for a short period of time for if it gives you any clue about the problem.


Ana

[Mark E. Levy]

Ana,

We began to have a lot more problems with BIND, so we installed ECO5 to solve that problem. After the update, IMAP started with the ACCVIO. I have another system still running ECO4 (it doesn't run IMAP) and also noticed that it was the same image. So, I thought that it might be some shareable library and installed all likely VMS patches. This seems to have reduced the incidence or the errors but not entirely eliminated them. I'll try what you suggested.

[Ana M. García Olivencia · Accepted solution]

Mark.

I forgot to say that althout our continuous IMAP accvios were solved restoring the original IMAP image, the problem hasn't solved at all, since sometimes we receive some of them. In fact, yesterday we had one and today we have had three ones (other days we don't receive anyone). Other times, the imap service is disabled and you have to shutdown and start. In this case, there are some TCPIP$IMAP_xx processes that are not killed (you have to do STOP/ID after the start). It seems that this second problem has something to do either with a great number of TCPIP$IMAP_XX processes or the time (a lot of days) the service has been enabled.

But returning to the original problem, somewhere I read that when you have an access violation, you can retreive some information from SDA passing the PC value appearing in the access violation message. For example, if the PC is FFFFFFFF80A7FBB0:

$ANA/SYSTEM
SDA>READ/EXEC/NOLOG
SDA>EXA/INS 80A7FBB0
DECC$SHR_EV56+D7BB0: LDQ_L R1,(R24)

If I execute that instruction for each access violation (some of them repeat the same PC), the references are for:
DECC$SHR_EV56
LIBOPTS
LIBRTL

I don't know if this gives you a clue or not.

If I have more info, I'll let you know.

Ana

[Mark E. Levy]

Ana,

I couldn't find any PTHREAD_DUMP.LOG files anywhere. When I enabled Server-Trace=True it would accvio every time and nothing useful appeared in the log.

[Volker Halle]

Mark,

the ACCVIO shown in your traceback indicates that the instruction at system space address 8083008C tried to WRITE to P0 space location 8DC000 and was not allowed to.

You would need the call stack information to try to find out, who has called that code with which parameters.

You can set a process to create a process dump for every improperly handled condition.

Consider to add:

$ SET PROC/DUMP

into SYS$SYSDEVICE:LOGIN.COM. Be prepared to find lots of process dumps in that directory later, when you are seeing lots of those errors.

You can analyse those process dumps with ANAL/PROC or even SDA.

Volker.

[Volker Halle]

Ana,

it's true that the failing PC may be in system space, but it's very unlikely, that that code has a problem. You can use the failing instruction together with the register contents to VERIFY, that the exception has been reported correctly.

Most of the time, the calling routine(s) has provided incorrect parameters. To find the calling routine, you need a process dump...

Volker.

[Mark E. Levy]

I did a side-by-side comparison of the Analyze/Image output from the ECO5 TCPIP_IMAP_SERVER.EXE and the ECO4 version. Although on the surface they appear the same and they report the same version number on startup, they are not the same.

************
File USER:[MARK]T.1;2
52 image file identification: "V5.4-15B"
53 image file build identification: "PCSI-0000000500"
54 link date/time: 19-MAY-2005 16:18:10.54
55 linker identification: "A13-02"
******
File USER:[MARK]T.2;2
52 image file identification: "V5.4-15"
53 image file build identification: ""
54 link date/time: 18-SEP-2003 22:00:45.27
55 linker identification: "A13-02"
************

I installed the EC04 version, we'll see what happens.

[Mark E. Levy]

Well, it's a little too soon to tell for sure, but dropping back to the ECO4 version of the image appears to have helped. It seems at this point that HP foobar'd the ECO5 changes. I was seeing 3-4 ACCVIOs a day before, and I've had none in the 14 hours since I switched images. Tomorrow will be the real test when the business workload picks up.

Apologies for the incorrect ECO number in the title.

[Mark E. Levy]

Well, it now HAS been long enough to tell, and the earlier version's IMAP server is far more stable. Whatever changes were made in the latest release broke it.