And Linux has the excellent valgrind. We had talks with IBM wrt porting purify to z/OS but nothing came of it. Unfortunately, the z/OS tools are expensive and buggy. DebugTool stands out as one of the worst products I've ever used.
On 11/10/2013, at 5:47 AM, Charles Mills <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
