On 11/10/2013 5:47 AM, Charles Mills wrote:
FWIW, MS Visual Studio 2010, which I use for editing and alpha testing, has
excellent memory leak diagnosis facilities.
Not only memory diagnosis tools but a complete development toolset.
Including a profiler that you can
attach to a running process (strobe, IBM APA etc). All that with a very
competitive price, free!
I'm an Ubuntu/Slickedit user myself and valgrind is the programmers best
friend. Of course, it has Memcheck,
but also cachegrind, a very nice cache and branch-prediction profiler. I
am very envious of our zVM/zLinux
brethren and their superior tool sets. They have access to the best of
breed open source software tools
that are not available to us on z/OS. I'm sure the IBM compiler have
internal tools, but if they ever make them
GA they will come with a premium price tag.
What I tend to do is develop as much code as possible on Ubuntu for fast
compiles and valgrind. It's not perfect but it's better than nothing.
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
