Is there really a reason to call a z/OS MEMORY ERROR a LEAK??? It's an ERROR. I know the Open Systems guys love to hide behind words that make it NOT seem to be their error, but why us???
Barry -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bernd Oppolzer Sent: Thursday, October 10, 2013 12:34 PM To: [email protected] Subject: Re: How diagnose potential memory leaks with LE? To diagnose memory leaks, I use an alternate heap manager called the "memory check heap manager". It keeps a statistic of all the allocated heap areas and prints a list of the unmatched allocates at the end of the process. This proved to be very helpful in our environment to find memory leaks in our mixed PL/1, C and C++ environment (most of the times, the memory leaks occur in the C++ programs). To use the mem check memory manager, you have to set some environment variables. I do it using CEEOPTS DD, that looks like this: //CEEOPTS DD * STACK(30M,10M),HEAP(4K,4K,,FREE),RPTSTG(ON),RPTOPTS(ON), ENVAR("_CEE_HEAP_MANAGER=CEL4MCHK", "_CEE_MEMCHECK_DEPTH=30", "_CEE_MEMCHECK_OVERLAY=OFF", "_CEE_MEMCHECK_TRACE=ON", "_CEE_MEMCHECK_OVERLAYLEN=8", "_CEE_MEMTRACE_DEPTH=30") that is, I first set the HEAP segments very low (4K) to get individual areas for almost all heap requests, and then - look at the ENVAR: the name of the alternate heap manager is CEL4MCHK the depth of the call stack printed is 30 - that is, 30 call levels are printed for the unmatched memory allocations - this was necessary for our environment, insurance math, where we have many function levels for the other parameters, please read the books - this must be described somewhere in the LE books - I don't know, because I got this from one of my co-workers, but I use it regularly and diagnose a lot of memory leaks this way - and very fast. It works much the same way as ValGrind on Unix and Windows - but I am faster :-) Kind regards Bernd Am 10.10.2013 15:23, schrieb Charles Mills: > My bad. Turns out it's not enough to put the new char[] in the > program, you have to put it where it actually gets executed. :-( > > 15C56358 00000000 00000070 CEEV#GH 1542C620 +00000000 > operator new(unsigned int) > 1521F790 +000000DC > operator new[](unsigned int) > 1521CD80 +000000C0 > main 15100160 +0000008E > EDCZMINV 1585604E -FFA14820 > CEEBBEXT 15306748 +000001C4 > > (BTW, no, there is no "automatic" delete inserted by the compiler for > every new. Yes, of course the storage gets deleted eventually -- the > customer does not have to buy more memory -- but a new without an > explicit delete = memory > leak.) > > Charles > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
