I believe the industry standard term for that particular type of memory error is "leak."
Charles Composed on a mobile: please excuse my brevity Barry Merrill <ba...@mxg.com> wrote: >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:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Bernd Oppolzer >Sent: Thursday, October 10, 2013 12:34 PM >To: IBM-MAIN@LISTSERV.UA.EDU >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 >lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
