07-20-2014 11:09 PM
Itanium OpenVMS 8.4 with no patches,
HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 2
on a _HP_ VMM (1.73GHz/6.0MB) running OpenVMS V8.4
This is a virtual machine in HPVM.
A customer has a command procedure that fails with "Insufficient dynamic memory".
This command procedure does mainly
$ tcpip mount
an NFS device
I asked him to add various
$ sh proc/memory
in his command procedure
With the default CTLPAGES, I saw CTLPAGES beginning to decrease after 486 iterations, and then, each iteration lost 0.55 Kbytes, until the error message.
I raised CTLPAGES to 2000 to allow the procedure to run longer, this time CTLPAGES decreased after 494 iterations, and eventually hit the error message.
There is clearly a memory leak.
I have looked at the text of the various patches for 8.4 and found nothing relevant.
Before applying Tcpip 5.7 Eco 4 and all the other patches, has anybody seen something similar ?
07-21-2014 04:55 AM
1) Is this a new problem or has this procedure always has this error?
2) If new, what changed?
These are usually "programming" problems that can be traced to either extremely large arrays being accessed (unknowingly) or to files being opened and not closed when processing completed as examples.
There is not enough info posted yet to help too much.
The description of CTL PAGES may provide you some clues:
CTLPAGES specifies the size of P1 pool. CTLPAGES is automatically changed only when the process logical name table, DCL symbols, or some layered products require an increase in the size of the P1 pool area.
07-21-2014 05:43 AM
07-21-2014 02:46 PM
Given your symptom
>With the default CTLPAGES, I saw CTLPAGES beginning to decrease after 486 iterations, and then, each iteration lost 0.55 Kbytes, until the error message.
I'd be interested to see exactly which command resulted in the memory loss, and which command generates the error when it occurs. It sounds like a bug, but without more detail about the body of the loop, it's difficult to say for sure. For example, are there any F$GETQUI calls to work out the queue entry? Maybe you're leaking queue context?
If the error is INSFMEM (I'd have thought, of all people, you would know that you should always paste exact and complete error messages!), in DCL context, that often means too many symbols or process logical names. Are your TCPIP MOUNT commands generating logical names which aren't being cleaned up? Check the symbol table and process logical name table the first time you see a bump in CTLPAGES.
That said, if it's not your own leak, even if you find a clear bug with a text book reproducer, I don't like your chances of ever getting anything fixed. So, your best bet is to try and work around the problem. One potentially simple way would be to isolate the body of the loop and execute it via SPAWN, that way the leaky sequence is done in a subprocess, so it's all recovered when the process exits.
07-21-2014 11:08 PM
The user has done a "clever"
$ set message/nofacili/nosever/noident/notext
in his command procedure, so the message in the log file is
Insufficient dynamic memory
I will restore the normal display
The command procedure loops doing
ssh "-q" "-o" "batchmode yes" 'node_name' @'comfile'
with node_name varying (60 nodes)
comfile varies, but does
tcpip mount dnfs
tcpip dismount dnfs
>>> I'd be interested to see exactly which command resulted in the memory loss, and which command generates the error when it occurs.
So do I :-)
I will add some other
inside the command procedures launched
There is not any call to f$getqui in this procedure or in the procedures called by the top one
>>>Check the symbol table and process logical name table the first time you see a bump in CTLPAGES.
Thanks, I will add it