Re: %DCL-W-SYMOVF, no room for symbol definitions - delete some symbols

Paul Raulerson wrote:

Okay, there are some misperceptions here about what CLISYMTBL is...

So the dump was not showing the current and starting size, just the maximum?


The bit the got snipped was the definition of CLISYMTBL as displayed by SYSGEN
or SYSMAN. This is a SYSGEN parameter, not a process quota, and is the number
of pages (pagelets) reserved for symbols in the process address space when a
process gets created. It is the same for all processes (though since it is
dynamic, you could tweak it, create a process, then change it back...)

I would have assumed that the in-memory signature started with the minimum possible
size for the image, and varied upwards as necessary. I would also have expected the
memory signature to decrease back to the base size during execution time; that fact
it did not do so if of course the key that identified the issue as a "memory leak"
- howsoever it was caused.

It's pre-allocated process virtual memory. Nothing to do with any images. DCL
symbols survive image activation and run-down and are stored in this chunk of
memory.


I don't think you are saying that the image was just loaded with the maximum size
at load time... but I could be making a really dumb assumption there.

Nothing happens at load time. The virtual address space is created at process
creation time (login or run/detached or spawn or batch job startup time), not
at image activation time.


OpenVMS seems to have a pretty simple executable image format, though simple
could be more an appearance than reality.

This is irrelevant to the present discussion, but I think on I64, VMS
actually uses ELF format, just like Linux. (I know it does for object
modules and object libraries, I'm not sure about executables, but they do
include the ASCII characters E, L and F in the 2nd, 3rd and 4th bytes.)


-Paul


Paul Raulerson wrote:

Boy, this is going to sound dumb, but didn't it just run out of space? >There
has to be a memory leak or some kind of failure to deallocate something
there - it is using 1024 pages, which is its maximum. It looks to me like >it
started with 512?

IIRC, the snipped stuff showed a current and max value of 1024 and a minimum
and default value of 512. Like any sysgen parameter, the min and max values
are the legal limits on the parameter. Outside that range, the system may
crash and HP will tell you "Go away" :-) The current value is what the
parameter was set to at boot time. The default value is what you get in an
out-of-the-box system if no one (or nothing) has changed it. (This parameter
is currently (VMS V8.3) a dynamic parameter, which means it can be changed
without rebooting, but it doesn't change automatically; someone has to
explicitly change it with SYSGEN or SYSMAN. "Dynamic" is indicated by a "D"
in the last column, which was snipped...)


I am probably wrong with this assumption, but it is such an easy answer...


I'll ignore the :-) here.

There does appear to be a leak here. The leak likely involves "constructed" DCL symbols -- symbols built at run-time to allow the construction of a DCL data array, for instance -- or potentially with logical names. It is conceivable that something else -- run-away allocation of I/O channels -- might trigger this leak (particularly if the run-time environment was already marginal), but symbols and logical names are the most common trigger.

The CLISYMTBL system parameter doesn't get bumped automatically, it gets bumped after a change to MODPARAMS.DAT and a reboot, or via a direct SYSMAN parameter change and a reboot. I'm not aware of any system parameter that changes itself; all changes require some sort of manual intervention, upgrade, AUTOGEN or other such. Some parameters require a reboot before the change takes effect, and some parameters can be changed dynamically.





--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
.

Relevant Pages

  • Re: Kernel memory leak in ATAPI/CAM or ATAng?
    ... > when the leak has occurred, and look for any marked differences. ... a memory leak resulting in address space exhaustion for the ... > tuning parameters for large memory systems. ... After reboot, it is <5K. ...
    (freebsd-current)
  • Re: %DCL-W-SYMOVF, no room for symbol definitions - delete some symbols
    ... There does appear to be a leak here. ... It is conceivable that something else -- run-away allocation of I/O channels -- might trigger this leak, but symbols and logical names are the most common trigger. ... The CLISYMTBL system parameter doesn't get bumped automatically, it gets bumped after a change to MODPARAMS.DAT and a reboot, or via a direct SYSMAN parameter change and a reboot. ...
    (comp.os.vms)
  • Re: MDAC memory leak
    ... Most libraries place the decision of when to free ... There's a capability of breaking on a particular memory allocation, ... leak 500 objects, on the second test I leak 3, because I fixed the bug). ... "App shows memory leak on some machines." ...
    (microsoft.public.vc.mfc)
  • Re: Random reboots with M2N-E (even worse now)
    ... error that happens during the reboot, ... I've known memory beeps to be 3 short ones, but this is on the Award ... When I couldn't find the 2.1V setting in the BIOS to adjust the memory ... you should get the same beep code. ...
    (alt.comp.periphs.mainboard.asus)
  • Re: MDAC memory leak
    ... Also when we used some of the memory leak tools suggested on microsoft site ... A mutex is a considerably less efficient synchronization ... "App shows memory leak on some machines." ...
    (microsoft.public.vc.mfc)