Re: virtual memory leak? (was: Re: strange problem.....)

ankisharma@xxxxxxxxx wrote:

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.

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.


.

Relevant Pages

  • Re: virtual memory leak? (was: Re: strange problem.....)
    ... and after some time I break this connection. ... executable in heap analyser and still there are no traces of memory ... The debugger is exceedingly programmable, too, ... I'm not a particular fan of malloc and free, ...
    (comp.os.vms)
  • Re: strange problem.....
    ... and after some time I break this connection. ... executable in heap analyser and still there are no traces of memory ... You can also program the debugger to display information, and to wait for specific conditions. ... 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. ...
    (comp.os.vms)
  • Re: Lost connection when start debug?
    ... memory management is shutting down the Bluetooth stack because the debugger ... needs more memory. ... on Bluetooth and debugging. ... needs COM1 (which is usually taken by the ActiveSync/USB connection) ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: strange problem.....
    ... we also have a memory manager. ... The debugger is exceedingly programmable, too, ... I'm not a particular fan of malloc and free, ... where calls made more directly to the underlying OpenVMS memory management have ...
    (comp.os.vms)
  • Re: [Lit.] Buffer overruns
    ... Each malloc() maps in a new pages. ... > un-maps the memory from the address space. ... Package: electric-fence ... Electric Fence is a debugger that uses virtual memory hardware to detect ...
    (sci.crypt)