Tracking down a memory leak in LV8.2 when you can't use the profiler

[clendon.gibson@metrosol.com]

I am working with this large application. I have satisfied myself that it does have a memory leak by watching the Window's Task Manager while using the app.

My first preference is to use the Profiler. However when I press 'Start' on the profiler, it instantly crashes LV. It does not do this for all VIs. I have tried to find the offending VI as narrowly as possible, but a VI that crashes profiler on one machine doesn't on another, so I gave that path up.
If someone knows of a thread about the profiler crashing, please point me that way.

Failing that, what kind of tips are there for tracking this leak down?

Thanks!

[Underflow]

Hiya,

Don't know of anything that will crash the profiler right off-hand, but it never struck me as the most... ah, robust bit of code in LV.

As far as pre-existing tools, you could try the memmon.llb that lives in the National Instruments/<labview>/examples folder.  It should show the memory load of each vi in memory, though it may require a little retooling to get things into a view that you like.

If you're on Windows, there are a number of tricks you can play with the SysInternals (now Microsoft) tools.  This usually boils down to watching lower level accesses to the operating system for patterns that look suspicious.  Not a high yield path, but occasionally it works.

For methods, I like divide and conquer.  The more portions you can eliminate as NOT having the problem, the fewer portions of your code you have left to look for problems in.

Tracking down memory leaks can be very difficult, but most show up in the end.

Good bug hunting!

Joe Z.