Review of memory leak tools on OpenVMS: Heap Analyzer, etc.

[Jon Pinkley]

Guy,

Nice you see you are back, it's been a while since I've you here.

Was your recommendation of PRF related to memory leak detection, or were you just recommending it in response to the "Other tool recommendations?" question?

Perhaps you were suggesting its use in determining why the Heap Analyzer is slow.

Or perhaps I am just missing something that is obvious. If so, how would PRF be used as a memory leak detection tool?

Jon

[Guy Peleg]

Guy,

Nice you see you are back, it's been a while since I've you here.

>>> I have been a silent observer of this
>>> forum lately.

Was your recommendation of PRF related to memory leak detection, or were you just recommending it in response to the "Other tool recommendations?" question?

>>> Personally, I do not like the heap >>>anaylzer due to all the problems
>>> encountered by Ben. I prefer to use PRF
>>> count the number of times memory >>>allocation/deallocation rountines been
>>> visited, maybe less trivial but less
>>> overhead.

Guy Peleg
Maklee Engineering
http://www.maklee.com

[Ben Armstrong]

In the end, HA did point us in the right direction, though soon after finding a suspicious routine we switched to Nvwa's debug_new.cpp because it was many times faster:

http://nvwa.sourceforge.net/doc/debug__new_8cpp.html

Before entirely giving up on HA, here are some things that helped:

- Increase the pagefile quota of the process running HA from 300,000 to 600,000, as otherwise I would run out of memory.

- Hide/collapse all images, etc. that were uninteresting. EXPREG and LIBRTL were where all of the activity was happening. This helped with the aforementioned issue with being able to scroll to the very bottom when zoomed in.

- Make liberal use of "SET BREAK foo DO (something; GO)" in order to see what's going on without having to watch the HA session. For instance, for my timings I did a SPAWN SHOW TIME at certain breakpoints.

Thanks again to everyone who answered. We have now identified and fixed the leak. I think we're going to continue to use Nvwa, given the success we've had with it so far.

Ben

[Hoff]

Guy's PRF comment reminds me; I've also used the basic FAKE_VM technique that John Gillings described in one of the VTJs, and (in addition to centralization and fenceposts) DECset PCA tool and the PCS tracing extension.

(That the existing OpenVMS memory management libraries aren't specifically instrumented is rather unfortunate. We all seem to end up rolling our own solutions on OpenVMS. Some of the tools around - at customer sites and in HP - are pretty good, but none of them seem to have been productized, or even distributed.)

(Dig through the available SDA extensions, too. Both the documented and undocumented - there are point solutions to a number of problems buried among those.)

And do look at the LLVM/Clang static analyzer. Or at IBM Purify. Or any of the other code analysis tools that are around.