Memory leak in Progress 9.1C

eddiej

New Member
We are encountering what appears to be a memory leak with one of our Progress batch programs that are running on our UNIX db server (HP-UX), Progress version 9.1C. Essentially the process errors out with the following error message: ** stget: out of storage; the current -hs value is 2000. Try a larger number (6497). Sometimes the error number is 1129 but the result is the same: the process dies and has to be restarted.

We initially suspected swap-space, but that is not it.

We suspect that the process is growing in size and buffers out. Has anyone ever encountered this before? If so, how did you get around it?

-Ed
 
Are you sure that the messages says "-hs"? That message usually says "-s".

Have you tried increasing -s like the message says?

-s is stack space for the 4gl session and is measured in units of 1k. It is primarily influenced by table schema definitions (so schema changes might cause a previously adequate value to no longer work) and recursion. Obviously recursive procedures that go too deep into the stack are going to cause problems. That kind of thing could be due to programming changes, data changes or usage changes.

And, of course, 9.1C is ancient and unsupported. You should upgrade.
 
I spoke too soon... :eek:

-hs is (or more properly was) a real parameter for a brief time. It seems to have been roughly the same as -s... The following Progress KCenter entry might shed some light if increasing it doesn't help:

ID: P24037
Title: ""Stget: out of storage" and "Unable to allocate more memory for records or variables. (4)" on SCO UnixWare."
Created: 04/28/2003 Last Modified: 01/12/2005
Status: Verified


Facts:
# Caldera Open UNIX/SCO UnixWare
# SCO OpenServer


Symptoms:
# Cleint connection is terminated.
# ** stget: out of storage. (1450)
# ** stget: out of storage. (6498)
# ** Error : Unable to allocate more memory for records or variables. (4)
# ** Error 12: Unable to allocate more memory for records or variables. (4)
# ** stget: out of storage; the current -hs value is <blocks>. Try a larger number (1129)
# Increased the -hs parameter.

Cause:
OS kernel parameters are set too low.

Fixes:
1. Change the HVMMLIM, SVMMLIM, SDATLIM, and HDATLIM kernel parameters to unlimited.

0x7FFFFFFF (ie unlimited)

2. Relink the kernel and reboot.
 
Tom,
Thanks for the feedback, but the info in your 2nd post is applicable to SCO UNIX, we are running HP-UX. Not sure if any of it is applicable.
 
I doubt that it's the kernel parameters but HPUX usually has analogues if it comes to that.

I would:

1) increase both -hs and -s
2) examine the code for any of the symptoms that I mentioned in my first posting

If that doesn't work then I'd start poking around for kernel issues.

(Actually the first thing that I would do would be to upgrade off of such an archaic and unsupported release as 9.1c...)
 
Back
Top