More fun. While waiting for the next Apache problem occurrence, I
happened to notice multiples of this:

%%%%%%%%%%% OPCOM 28-DEC-2021 09:29:25.85 %%%%%%%%%%%
Message from user INTERnet on ITS
INTERnet ACP NOLISTEN Process creation success: Service - BIND

Log file (SYS$SPECIFIC:[TCPIP$BIND]TCPIP$BIND_RUN.LOG) ends so:

Tue 28 09:30:52 CRITICAL:
BUILD32$:[TCPIP_V57_BLECO5.SRC_PAT.BIND9_SERVER]MEM.C;1:639:
INSIST(((unsigned char *)mem)[size] == 0xbe) failed
Tue 28 09:30:52 CRITICAL: exiting (due to assertion failure)
%SYSTEM-F-OPCCUS, opcode reserved to customer fault at PC=FFFFFFFF84865CA0,
PS=0000001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000003
Name = 0000000000000434
FFFFFFFF84865CA0
000000000000001B

Register dump:
R0 = 0000000000000000 R1 = 000000007B528000 R2 = 0000000000A1A480
R3 = 000000000000000A R4 = FFFFFFFF844D4910 R5 = 0000000000000000
R6 = 0000000000000000 R7 = 0000000000000000 R8 = 0000000000000000
R9 = 0000000000100000 R10 = 0000000000100000 R11 = 0000000000000000
SP = 0000000000A1A4D0 TP = 0000000000A1D200 R14 = FFFFFFFF844BE1A0
R15 = 000000007B897E80 R16 = FFFFFFFF841DF710 R17 = 0000000000100000
R18 = 000000007B6F33B8 R19 = 00000000005CE0A0 R20 = 0000000000000001
R21 = 0000000000000000 R22 = 0000000000A1A4B0 R23 = 0000000000000000
R24 = 000000007B8535E0 R25 = 0000000000000001 R26 = 0000000000000000
R27 = 000000000000005C R28 = 000000007B3393C8 R29 = 0000000000A191A0
R30 = 000000000000000F R31 = 00000000000001B0 PC = FFFFFFFF84865CA0
BSP/STORE = 000007FDBFE824D8 / 000007FDBFE824D8 PSR = 0000101308026030
IIPA = 0000000000000000
B0 = FFFFFFFF84865CA0 B6 = FFFFFFFF841DF710 B7 = FFFFFFFF844BE1A0

Interrupted Frame RSE Backing Store, Size = 16 registers

R32 = 0000000000000006 R33 = FFFFFFFFFFFFFFFE R34 = 0000000000000434
R35 = 0000000000000000 R36 = 0000000000000001 R37 = 00000000000505B0
R38 = C000000000000593 R39 = 0000000000790000 R40 = FFFFFFFF845D1BB0
R41 = C000000000000184 R42 = 000000007BA7A000 R43 = 0000000000000434
R44 = 0000000000000000 R45 = 0000000000A1A4EC R46 = 0000000000A1A4B0
R47 = 0000000000A1A4B0
%CMA-F-EXIT_THREAD, current thread has been requested to exit
TCPIP$BIND job terminated at 28-DEC-2021 09:30:52.06

Accounting information:
Buffered I/O count: 3553 Peak working set size: 22144
Direct I/O count: 71 Peak virtual size: 206288
Page faults: 1537 Mounted volumes: 0
Charged CPU time: 0 00:00:00.49 Elapsed time: 0 00:01:26.21

ITS $ tcpip show vers

HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 5
on an HP rx2600 (1.50GHz/6.0MB) running OpenVMS V8.4-2L3

It's up to TCPIP$BIND_61 after about six days.

Without knowing what's happening around MEM.C;1:639, I don't know
what to investigate. User/process quotas? DoS attack? ...?

Steven,

this seems to be a known TCPIP bug. Just search for 'INSIST(((unsigned char *)mem)[size] == 0xbe) failed'

see:

https://support.hpe.com/hpesc/public/docDisplay?docId=pdbVSI_I641520615901321&docLocale=en_US

supposed to be fixed in: VSI-I64VMS-TCPIP_PAT-V0507-ECO5O-4.zipexe

If you believe you have that patch installed, it's escalation time to VSI support.

Consider to issue a $ SET PROC/DUMP/ID=<pid-of-running-BIND-server>, then wait for the next BIND process crash to happen and look for the *.DMP process dump file.

Volker.

> this seems to be a known TCPIP bug. [...]

Yup, that looks like it. Thanks for the pointer.

> supposed to be fixed in: [...]

Hmmm. I seem not to have installed the
VSI-I64VMS-TCPIP_PAT-V0507-ECO5O-4 kit which I see on the I640842L3OE
DVD. I'll try that.

> supposed to be fixed in: VSI-I64VMS-TCPIP_PAT-V0507-ECO5O-4.zipexe

Seems to be true. 30 hours later, TCPIP$BIND_1 is still running. Of
course, I should have found it myself, but the help is appreciated.

Applying that patch kit seems to have stopped the runaway Apache
subprocesses, too.

Remarkably, some weeks ago, when I installed V8.4-2L3 on my
fancy/experimental rx2660, I managed to install that kit; on the
serious-work system, I failed to pay attention. Sigh. Trust no one, I
always say.

On 2021-12-29, Steven Schweda <sms.antinode@gmail.com> wrote:
>
> Remarkably, some weeks ago, when I installed V8.4-2L3 on my
> fancy/experimental rx2660, I managed to install that kit; on the
> serious-work system, I failed to pay attention. Sigh. Trust no one, I
> always say.

It happens. :-)

I always like people to review my work/code just in case I have made
a silly mistake. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.