[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:	VAX and Alpha VMS
Notice:	This is a new VMSnotes, please read note 2.1
Moderator:	VAXAXP::BERNARDO

Created:	Wed Jan 22 1997
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	703
Total number of notes:	3722

202.0. "LIB$SHOW_VM statistics?" by FORTY2::ACISS2::LENNIG (Dave (N8JCX), MIG, @CYO) Mon Feb 17 1997 10:08

    I've been trying to track down some memory leaks in an application.
    FAKE_VM has proven quite helpful in this regard, and has allowed us
    to close a number of them. However, LIB$SHOW_VM is still showing
    evidence of a couple of leaks (we suspect it's our dynamic string
    usage, which FAKE_VM doesn't really help with).
    
    One of the puzzling things that LIB$SHOW_VM is reporting, that I'm
    having trouble grasping, is that our image is making significantly 
    more calls to LIB$FREE_VM than to LIB$GET_VM. Has anyone else seen
    anything like this before, or have any ideas as to the discrepancy?
    
    Dave

T.R	Title	User	Personal Name	Date	Lines
202.1	Questions...	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Mon Feb 17 1997 10:16`	5
	Is the application checking and reporting status failures on RTL calls? Is the application (incorrectly) attempting to perform `partial' memory deallocations? Is the application storing dynamic string descriptors on the stack?
202.2		QUARK::LIONEL	Free advice is worth every cent	`Mon Feb 17 1997 11:40`	4
	You might also want to try using the debugger's Heap Analyzer. It can tell you from where in the program each allocation was made. Steve
202.3		FORTY2::ACISS2::LENNIG	Dave (N8JCX), MIG, @CYO	`Mon Feb 17 1997 12:07`	26
	re: .1 Based upon FAKE_VM testing, I'm reasonably certain that all GET/FREE calls made by the application (and the other images that it uses) are working/successful. The only exception is GET/FREE calls within LIBRTL, since FAKE_VM can't intercept those. LIB$SHOW_VM_ZONE is not reporting any errors against either the default or string zones (so we're not allocating out of one area and freeing into the other). If we were attempting to do partial deallocations, I believe FAKE_VM would have reported this. Based upon further work today, the remaining leak is definitely coming out of the string zone, so it's simply a matter of tracking that down. The real question is the GET/FREE count discrepancy. For example, after having reached a steady state, I consistently see 180 calls to GET_VM per major loop in the application (for one a particular test case), but the FREE_VM count varies from 246 to 274 calls. So not only are there more FREE calls than GETs reported by SHOW_VM, but the number varies... re: .2 debugger Heap Analyzer?? I'll check it out. Thanks, Dave
202.4		QUARK::LIONEL	Free advice is worth every cent	`Mon Feb 17 1997 14:01`	4
	Some applications GET a large chunk of memory and then FREE smaller pieces of it. This is invalid, but you can sometimes get away with it. Steve
202.5		FORTY2::FOOTE		`Wed Feb 19 1997 08:37`	11
	Thanks Steve, using the debugger's Heap Analyzer tool has cleared up the remaining memory leaks [sounds of champagne corks popping in the background]. However, we are still seeing more calls to LIB$FREE_VM than to LIB$GET_VM. Is there any way we could use the Heap Analyzer to find out what's going on here? Thanks, Chris
202.6		QUARK::LIONEL	Free advice is worth every cent	`Wed Feb 19 1997 10:36`	3
	I'm not sure about that - ask in TURRIS::DEBUG. Steve