Endless loop in SYS$EXIT (7.2-1)

[Peter Hofman]

We are having a strange problem. We do not currently know the exact scenario, but for some reason a process got into an endless loop in SYS$EXIT, and cannot be stopped with STOP/ID=.
The process takes up all CPU on one of the 2 available CPUs.

The instruction the process hangs at is:

SYS$EXIT_C+520 BR R31, #xFFFFFF

This sets back the PC to the same instruction.

The problem occurs in OpenVMS 7.2-1, but we know that the code above is also in OpenVMS 7.1-2.

What I am wondering about is:
- Why would you want to have an endless loop in system service?
- Is there a way to stop the process other than rebooting?

Since OpenVMS 7.2-1 is not really supported anymore, I suppose it is no use sending a crash dump to HP for analysis.

[Ian Miller.]

check the process carefully. You may find an outstanding I/O or other incomplete activity.
At what scheduling priority is the process looping?

[Galen Tackett]

Is there some way that this could be a screwy inner-mode exit handler? I'm not wise enough to tell you how (or whether) that's possible, but perhaps this will tip off someone smarter than me...

[John Gillings · Accepted solution]

The code you're most likely looping in looks like this:

$DELPRC_S
PUSHL R0
$SETPRI_S PRI=#0
POPL R0
25$: BRB 25$

The $DELPRC is supposed to kill the process and never return, but if it returns, the process will set its priority down to 0 and loop.

Why? Well, it's defensive programming. The $DELPRC shouldn't return, but just in case it does, we put the process into a "harmless" state. There are other possibilities, like $HIBER, but what if that fails too? The BRB is pretty much foolproof and is has the secondary benefit that the system manager is more likely to see a rogue COM state process than a HIB.

Note that the status from the failed $DELPRC is saved, so you should be able to look at it from SDA. Set process then:

SDA> EXAMINE R0
SDA> EXAMINE/CONDITION R0

Of all the documented condition values, I'd guess SS$_INSFMEM.

Since the process is at priority 0, it shouldn't really hurt much, just consume a process slot and some memory. There is no way to get rid of it other than rebooting.

Not a lot of point in sending the crash dump to your CSC. As well as the support status for V7.2-1, about the only thing of interest is the value in R0. Why send a whole crash dump when a longword will do?

[Peter Hofman]

Thanks for your help!

Priority is indeed set to 0.

EXAMINE /COND R0
gave the following response:
%SYSTEM-F-NODELETE, object cannot be deleted

The NODELETE flag is set in the PCB.
This is done (temporarily) to prevent other users from killing the process when doing certain database transactions.