Just to add some remarks: the report of this mem check heap manager looks almost exactly like the ValGrind report, which has been mentioned by another poster, (and we have ValGrind at our site, too, for the Linux variant of our math package, so I had the chance to compare the reports), and it has the sequence number of the allocation as well.
And, as far as I understand, it is part of the normal LE distribution, at no additional cost. Kind regards Bernd Am 11.10.2013 01:33, schrieb Charles Mills:
Forgot to say thanks, Bernd. This looks interesting. I wonder why they have three of these memory leak reports? ("Mine" plus "yours" plus something called "_VHM_REPORT" -- see the Vendor Interface manual.) Three mediocre reports instead of one good one? Now that I understand the other report I am content with it, but I will keep this in mind. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bernd Oppolzer Sent: Thursday, October 10, 2013 10:34 AM 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
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
