FWIW, MS Visual Studio 2010, which I use for editing and alpha testing, has
excellent memory leak diagnosis facilities.
You can turn on leak monitoring, and unlike LE, the overhead is low enough
that you can leave it on through most testing.
Here's the error from my abandoned new char[99]:
Detected memory leaks!
Dumping objects ->
{303} normal block at 0x009D8408, 99 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
Much clearer than what LE puts out IMHO. For example, it gives the "user"
length of the allocation, not the length as rounded up and decorated with
control blocks as LE does. If you need more detail -- see that number 303?
That says it was the 303rd heap allocation by the program. You can set a
switch that says "breakpoint on heap allocation #303," run it again, and
bingo, you can see the offending instruction, the entire call stack, all of
the relevant variables, and so forth.
Not an MS commercial; just trying to set the record straight and say that
"no decent tools" is not much of an excuse.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of zMan
Sent: Thursday, October 10, 2013 2:33 PM
To: [email protected]
Subject: Re: How diagnose potential memory leaks with LE?
Ditto. I think they like 'leak' because they have no decent tools (in too
many cases, not all!) to diagnose it. I see teams do things like "Run this
for a week and see if it runs out of memory", rather than "Run it for 1M
iterations, measure memory before, during, and after". What, they think that
after six days, it's going to say "Ooh, I think I'll use more memory all of
a sudden"??? (Yes, that COULD conceivably happen, but a
day/week/month/year/decade are almost equivalent if you have no clue what
might cause it; if you declare victory after a week, it might have been
*about* to occur...)
On Thu, Oct 10, 2013 at 5:25 PM, Charles Mills <[email protected]> wrote:
> Gee, I agree with John. I must be having a mellow day.
>
> Seriously, I don't think "leak" absolves blame. If you had a water
> leak it would definitely be a fault, not a "situation." "Leak" seems
> to perfectly characterize what happens: the region has lots of free
> memory, the program runs for a while, and now the free storage has
mysteriously disappeared.
> Where did it go? It leaked.
>
> The LE manuals use the term "storage leak problems."
>
> Of course, it's not really a storage or memory problem at all. It is a
> "failure to free" error. Memory is fine; the problem is the absence of
> free or delete instructions. Except for the fact that "memory leak" is
> an established term that most folks agree on and recognize, I would
> support the terminology "failure to free" error.
>
> Charles
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]]
> On Behalf Of John Gilmore
> Sent: Thursday, October 10, 2013 11:57 AM
> To: [email protected]
> Subject: Re: How diagnose potential memory leaks with LE?
>
> Barry Merrill wrote:
>
> <begin extract>
> 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???
> <end extract/>
>
> and I strongly agree that the use of euphemisms for what are in fact
> errors is undesirable.
>
> In this case, however, the use of 'leak' instead of 'error' is a very
> old practice. The phrase 'storage leak' has been used at least since
> the 1970s to characterize situations in which dynamically allocated
> [usually] heap storage is incompletely freed at the end of its use, so
> that the total amount of this storage available gradually diminishes,
> leaks away, until processing can no longer continue or performance
> deteriorates spectacularly.
>
> Here, I think, some loss in precision would attend using a generic
> term like 'storage error' instead of the traditional one.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] with the message: INFO IBM-MAIN
>
--
zMan -- "I've got a mainframe and I'm not afraid to use it"
----------------------------------------------------------------------
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
