Re: virtual memory leak? (was: Re: strange problem.....)
- From: ankisharma@xxxxxxxxx
- Date: 18 Aug 2006 02:43:15 -0700
Hoff Hoffman wrote:
ankisharma@xxxxxxxxx wrote:Following is the output of 'prod show prod *'
The page file and WS quota of my VMS process are decreasing at a
rapid rate. This is happening in a particular scenario in which some
remote entity connects with my sctp server. I accepts the connection
and after some time I break this connection. Earlier I thought there
could be some memory leak so I introduced printf statements at
malloc/free calls but unable to find the leak. Then I run the
executable in heap analyser and still there are no traces of memory
leak.....
If anyone faced a similar problem then please tell me how could I get
to the root of the problem...
Ensure your OpenVMS version and your IP stack version -- whichever IP stack
you are using -- are current, and that your ECOs are current.
----------------------------------- ----------- ------------
PRODUCT KIT TYPE STATE
----------------------------------- ----------- ------------
COMPAQ AXPVMS FMKCTF V2.8 Full LP Installed
COMPAQ AXPVMS FMKLIC V1.2 Full LP Installed
COMPAQ AXPVMS FMKTBX V2.8 Full LP Installed
COMPAQ AXPVMS IN7_CCITT V4.1-5 Full LP Installed
CPQ AXPVMS CDSA V2.0-109 Full LP Installed
DEC AXPVMS DECNET_OSI V7.3-2 Full LP Installed
DEC AXPVMS DWMOTIF V1.3-1 Full LP Installed
DEC AXPVMS OPENVMS V7.3-2 Platform Installed
DEC AXPVMS SEA V4.3-0 Full LP Installed
DEC AXPVMS TCPIP V5.4-15 Full LP Installed
DEC AXPVMS VMS V7.3-2 Oper System Installed
DEC AXPVMS WCCPROXY V1.0-0 Full LP Installed
DEC AXPVMS WEBES V4.3-0 Platform Installed
HP AXPVMS KERBEROS V2.0-6 Full LP Installed
----------------------------------- ----------- ------------
Use periodic $getjpi calls, as well.
You can also program the debugger to display information, and to wait for
specific conditions. (And if you're adding printfs in the fashion cited, it
could be inferred that the application code and particularly its error handling
and recovery could use a review. The debugger is exceedingly programmable, too,
meaning you can code the debugger to monitor for an error and then display
information, or to execute sequences that display the values of the specified
values as they change, etc.)
I'm not a particular fan of malloc and free, as the mechanisms are overly
generic. I tend to use a combination of fenceposts -- details at the old Ask
The Wizard site (www.hp.com/go/openvms/wizard) -- and centralized memory
management. Having malloc and free calls scattered around the source code is
also not something I tend to prefer, as it makes debugging problems in this area
rather more difficult -- much like having protocol-level or network-level
communications API information or knowledge scattered around an application,
having malloc and free scattered just makes maintenance and upgrades that much
more difficult.
And as for one of the more subtle problems with malloc and free, and
depending on how the calls are made, you can end up fragmenting pool which can
lead to increasing virtual memory usage. Calls to malloc and free are also
more difficult to monitor for run-time corruptions (hence the fencepost stuff),
where calls made more directly to the underlying OpenVMS memory management have
access to heap verification tools and monitoring tools; see the LIB RTL VM
services routine calls -- there's a chapter or two in the programming concepts
manual, IIRC. lib$get_vm, lib$free_vm, lib$stat_vm, VM zones (and the zone
construct is exceedingly useful, as it can avoid fragmentation, and it can
easily allow "temporary" memory to be freed en-mass, etc).
There are a number of discussions of debugging memory management errors and
pool leaks over in the old Ask The Wizard area, too. See topic (3257), and
others referenced from there throughout the ATW area.
.
- Follow-Ups:
- Re: virtual memory leak? (was: Re: strange problem.....)
- From: Peter 'EPLAN' LANGSTOEGER
- Re: virtual memory leak? (was: Re: strange problem.....)
- References:
- strange problem.....
- From: ankisharma
- Re: virtual memory leak? (was: Re: strange problem.....)
- From: Hoff Hoffman
- strange problem.....
- Prev by Date: Re: Open Source Hardware? (SPARC)
- Next by Date: Re: strange problem.....
- Previous by thread: Re: virtual memory leak? (was: Re: strange problem.....)
- Next by thread: Re: virtual memory leak? (was: Re: strange problem.....)
- Index(es):
Relevant Pages
|