Two additional hints:
the output goes to CEEMSGS, and:
this is not meant for production work, of course,
because the use of CEL4MCHK makes your application really slow;
it's only for diagnosing memory leak problems.
Kind regards
Bernd
Am 10.10.2013 19:34, schrieb Bernd Oppolzer:
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
