Ridiculously low PQL_MPGFLQUOTA hangs process in COM?

[Galen Tackett]

This problem is on a DS10 VMS V7.3-2 system with pretty much current patches. (The latest one or two might be missing but it does have UPDATE V4 installed.)

There's a lot to read here, but I hope you'll plow on through.

I had been having a problem with gawk v3.1.4 running out of pagefile quota while executing a very trivial do-nothing script. While trying to figure this out I had set (SYSGEN WRITE ACTIVE) a very low PQL_MPGFLQUOTA of maybe 2500 pagelets. That's probably far too low, of course, and later one of my processes became "stuck."

The process (_FTA32:) was in COM state but wouldn't respond to Ctrl/Y and wouldn't abort with STOP/ID=xxx. It also appeared that SET PROCESS/SUSPEND/ID=xxx was ineffectual as the process continued to show as COM.

I tried to do a SHOW PROCESS/CONTINUOUS on the process but never got a display and had to just Ctrl/Y out of that. Since it was slowing things down I set its priority to 0, which appeared to work though response was still slightly sluggish.

Since I really wanted to know what it was executing, I next tried F$GETJPI(pid, "IMAGNAME") which returned a null string. ?!?

At this point I just ran OPCCRASH to force a crash and capture whatever was going on.

Once everything was back up I took a look with SDA. I can't easily post very much of the result as the system is only on a private network and has no way to write any removable media. So I'll summarize what I saw, and then if more information is needed, I'll try to transcribe it if possible.

SDA> SET PROCESS _FTA32:
SDA> SHOW PROC/IMAGE
!
! Summarized:
!
! LOGINOUT
! CLIUTLMSG
! DCL
! SYS$PUBLIC_VECTORS
! SYS$BASE_IMAGE
!
! (I may have been trying to log out when the process hung up.)
!
SDA> E/I @PC
MMG$UNLOCK_SYSTEM_PAGES_C+00430: LDL_L R1, (R19)
SDA> E @R19
JIB+44: FFFFFF30
SDA> EVAL JIB+44
FFFFFFFF.812D0644
SDA> FORMAT JIB
!
! Extracted something hopefully interesting
! Leading FFFFFFFF. suppressed
!
812D0640 JIB$L_PGFLQUOTA 0000009D
812D0644 JIB$L_PGFLCNT FFFFFF30

It struck me as a little odd that the pagefile count was negative (-208). Perhaps the very low PQL_MPGFLQUOTA caused the process, while running down (logging out) to wind up with this negative value and thus go into an infinite loop?

[Volker Halle · Accepted solution]

Galen,

looks like this code is inside the $more_pgflquota macro used in module [SYS]SYS_CREDEL_64 routine $charge_page.

R16 should point to JIB and R19 to JIB$L_PGFLCNT inside the JIB.

The routine tries to 'Get more pagefile quota cache'.

JIB$L_PGFLCNT is the 'remaining pagefile quota' (from LIB.REQ: Paging file limit *** signed ***) and should probably not become negative.

Volker.

[Galen Tackett]

Volker,

<>

[I guess that one's pagefile quota doesn't come with overdraft protection. :-]

That's kinda what I figured. The case I ran into might be considered at least borderline pathological, but I was understandably surprised to see a pagefile count less than zero and the process in an infinite loop with no executing image name visible.

No software contract here, so no official problem report possible. :-|

But there's no serious impact either. :-)


Thanks,

Galen

[John Gillings]

Galen,

If you get a chance, try to reproduce this under V8.2. If it still fails send me mail with as complete as possible description on how to cause it. I'll see if we can get it entered on a bug list.

Understandably, engineering doesn't have a whole lot of time to investigate "shoot self in foot" issues ;-)

Could everyone please go check out the real cost of disk and RAM and re-calibrate your thinking in terms of OpenVMS quotas.

PGFLQUOTA=2500 is only 1.2MB - that's such an insignificant chunk of disk space that it's worth only a fraction of a second of anyone's time.

Yes, you can cause all kinds of pathological things to happen by constraining OpenVMS processes, and engineering don't probe all the behaviours at resource limits.

Maybe it's time we set some hard minima on PQL_M parameters?

[Galen Tackett]

John,

I completely understand that this kind of issue isn't one that would typically be tested for. The specific value I chose for PQL_MPGFLQUOTA was rather arbitrary. I just wanted a number that was large enough to let me log in and run gawk, and small enough to cause gawk to run out of virtual memory. Guess I aimed too low (towards my foot :-) and should also have considered "large enough to allow me to log out."

I do have V8.2 handy on an IA64 box. I just need to set the pgflquota minimum really tiny and try this out there.

Thanks,

Galen

P.S. My original [non-VMS] problem, which doesn't really concern you I guess, involves gawk v3.1.4 running out of virtual memory in its parser. The problem is platform dependent--it doesn't occur under OS X, Windoze, or Linux--so I'm really curious to see if VMS V8.2 plus IA64 works.

[Lawrence Czlapinski]

John, in today's highly competitive environment buying more disks and memory is not what management wants. Often that doesn't even make the project cut list unless it is tied into some project that can justify the cost of a project. I have a zero budget.
Lawrence

[Willem Grooters]

I have to agree with Lawrence. It's about time HP realizes that VMS is used in SMB (and smaller) as well - and where other OS's are no option (security, robustness - you name it all)

Willem