topic Re: Memory leak in CMS in Operating System - OpenVMS

Memory leak in CMS

Michael Steve — Wed, 02 Mar 2011 16:38:21 GMT

Using CMS Vers. 4.6 on OpenVMS V8.4 on an Itanium.

There is a fairly large memory leak in all CMS commands that use the CMS DIF functionality. (CMS VERIFY, CMS DIF, CMS REPLACE/IF....). The memory is restored on completion of the CMS task.

My current workaround is to only use these commands on individual elements in DCL.

I'm not having much luck finding a proper contact to send this information.

Re: Memory leak in CMS

Hoff — Wed, 02 Mar 2011 17:10:08 GMT

The support center is the usual path for reporting these bugs.

I don't know off-hand if CMS 4.6 is current or if there are patches for it. The support center would know, and would know if there are patches for CMS that haven't been generally released.

If you don't have a support contract, then you can try submitting a reproducer for the bug to the OpenVMS programs office Openvms.programs@hp.com and posting a copy of the reproducer somewhere on the 'net for other folks.

Re: Memory leak in CMS

John Gillings — Wed, 02 Mar 2011 20:30:19 GMT

Michael,
I'm not sure I understand your problem.

>The memory is restored on completion of
>the CMS task.

This isn't the usual definition of "leak". If the memory is restored, it hasn't leaked.

What is the symptom you're experiencing which makes you think there's a problem?

Are you sure the commands aren't just using more memory than you expect? Perhaps you could fix the issue by increasing quotas?

Re: Memory leak in CMS

Mike Kier — Wed, 02 Mar 2011 20:32:58 GMT

John,

I think perhaps he meant the memory is restored on image rundown - i.e., if each CMS command is an individual DCL verb, then all is well.

But if you enter CMS and work from the CMS> prompt then you will hit the memory limit at some point.

Re: Memory leak in CMS

Michael Steve — Wed, 02 Mar 2011 22:19:45 GMT

When using CMS commands that work on multiple elements and uses CMS DIF internally, CMS will allocate memory per element iteration and not properly free the memory until it has completed the entire task. This also affects anyone who uses the CMS CALL ROUTINE CMS$DIFFERENCES().

For example, from DCL:

$ CMS VERIFY

This command by default will work on all elements within the library, if there is a reference copy, then the command will use the CMS internal dif routine for each element. For me, after about 50 elements I get this:

%CMS-F-BUG, there is something wrong with CMS or something it calls
-CMS-F-SYSFAIL, SYS$CRETVA system service request failed
-SYSTEM-F-EXPGFLQUOTA, exceeded pagefile quota

Its been fun running this command while watching the process with PROCMON. Sure boosting my page file quota will increase the number of elements processed, but it doesn't fix the underlying problem (nor the fact that one of my CMS libraries has 4000 elements in it).

so the way around this for me is to create a COM file like so:

CMS SHOW ELE *.* /FORMAT="$ CMS VERIFY #E" /OUT=CMSV.COM.

In this way, I'm freeing the memory with every call, which CMS isn't doing with each iteration when using the wildcards. This is slower, but it at least will complete.

Very few commands use the diff CMS call routine. CMS DIF is "okay" because it doesn't allow wildcarded elements.

Re: Memory leak in CMS

Brian Reiter — Thu, 03 Mar 2011 08:03:31 GMT

Mike,

I had similar issues with CMS 4-6 but these showed up with LIB$FREE_VM. The case number is 4616365989 (if that is any help) which was raised sometime round September last year. I don;t know if the fix is available yet, I may have look around and see if can find a recent patch kit.

cheers

Brian

Re: Memory leak in CMS

Ian Miller. — Thu, 03 Mar 2011 09:47:37 GMT

DECSET 12.8 ECO2 is the latest kit I've seen.

Re: Memory leak in CMS

Brian Reiter — Thu, 03 Mar 2011 10:10:02 GMT

How soon would a ECO become available for DECSET? ECO2 was definitely the one I had problems with, HP seemed disinclined to let me know when any formal kits would be produced.