Detached process executing BASIC program slowly runs out of page file quota

[Dan Herron]

Hi everyone,

We are perpetually executing a BASIC program as a detached process that wakes up every 5 minutes, and if there is work to do, performs the work (updates to RMS files and Rdb database tables) then goes back to sleep. The process slowly (over many days) eats up page file until it exceeds its quota. I have never seen this behavior in a BASIC program (at least not that I have written, and no, I did not write the program in question!), and thought BASIC to be fairly impervious to memory leaks and such. I have analyzed the code and cannot find any statements that might cause the problem. There are no dynamically allocated arrays or other constructs that dynamically allocate memory, no global variables, NO GOSUBS with missing RETURN statements, no files left open between sleep periods, etc.

Does anyone have experience with this problem, or expertise in leaking BASIC program?

Thanks,
Dan Herron

[Robert Brooks_1 · Accepted solution]

Well, it may not be the BASIC code itself
that is the problem; what shareable images
are activated?

Are you using callable SQL?
(I'm not attempting to implicate SQL, but offering that as a possibility).

--Rob (who enjoys using
BASIC to do quick-and dirty stuff in kernel
mode)

[Hein van den Heuvel]

>>> no files left open between sleep periods, etc


Maybe it should... just keep them open.

>>> The process slowly (over many days) eats up page file until it exceeds its quota.

Maybe to most cost-effective solution is to have the process re-start itself once a day (Basic CHAIN, or LIB$DO_COMMAND?).

Do any of those files have global buffers?
We have seen 'address laddering' where virtual memory for the global buffers interacts with virtual memory for lib$get_vm and friends. Global buffers are mapped during SYS$CONNECT with SYS$CRMPSC + EXPREG. They are un-mapped with $DELTVA in $DISCONNECT ($CLOSE). However, that deltva is only effective if it is the last VA in use. So... you'd have to either
- close your files in LIFO order: Open 1,2,3 ... close 3,2,1 which most application do not do.
- make an extra effort to keep files with globla buffers open
- disable gloabl buffers for this process through USEROPEN setting FAC$W_GBC=0 between $OPEN and $CONNECT.

Now thise is 'just VA' and shoudl not influence 'pagefilequota' directly, but I can readily imagine further interactions.

How much memory are you loosing? A little bit per-cycle, or like 128 KB every so many cycles? I suspect the latter, as LIB$GET_VM will eventually need to do an EXPREG. You may get a better picture by adding a call to LIB$SHOW_VM when going to sleep.

You may be able to create a workaround by doing an explcit GET_VM for 'a lot', say 10MB at program start and releqasing immediately. This will prevent 'laddering' of Virtual Memory use: VM - RMS-buffer - RMS-structures - more VM - more RMS structures - more VM - more RMS buffers ....


Good luck!
Hein.

[Dan Herron]

The program uses precompiled SQLMOD procedures to access the Rdb database tables, so there are no dynamic SQL calls in the program.
The RMS files do not have global buffers associated with them.
The BASIC code does not have any calls to LIB$GET_VM. All the memory allocation statements are created by the BASIC compiler in response to standard BASIC instructions within the source code.
There are no calls to any shared application images.

[Hein van den Heuvel]

>> The BASIC code does not have any calls to LIB$GET_VM

Understood, but a simple A$="test" will do a an implicit get_vm under the cover.

I you can 'snap' the process while active, then you may want to use ANA/SYS... SET PROC "your server"... SHOW PROC/RMS=(RAB,FAB,BDBSUM,GBH,NOIFB=XX) and monitor the addresses as they move (or not). The xx woudl be the 'IFI' from a FAb for a significant file for the server.

Hein.

[Ian Miller.]

There has been memory leaks with some versions of RDB. It may be worth checking with oracle about that.

[Antoniov.]

Dan,
I'm with Hein: in BASIC a simple A="B" allocate dynamic memory.
However this implies a trouble in garbage collector of BASIC RTL.
I don't know the VMS version but in MS-BASIC there is a FREE("") statement to brute force garbage collection; you could execute it before sleep process.

Antonio Vigliotti

[Vouters]

Hi Dan,

Which VMS version ? VAX, Alpha or IA64 ? Which version of the BASRTL ? Which optimization level did you use when compiling ? Did you try using both the debugger and the Heap Analyzer, running your program interactively to locate when the leak occurs ? Did you DBG> DUMP the leak ?

Is this leak observed following an upgrade of either VMS or the compiler ? Can you post a $ PRODUCT SHOW HISTORY ?

Hoping these questions can help you in identifying the leak.
Philippe