LabVIEW
Handling Reference Leaks via Dynamic Calls
Solved!
In the past I've asked about the security of password protecting VIs. The technique NI uses is quite weak, because of some other design choices of LabVIEW that go back 30 years or so. A password protected VI, cannot encrypt the contents of the VI, because the source needs to be available to the compiler, so it can be opened in newer versions of LabVIEW, and potentially because other external dependencies changed, now requiring a recompile.
What this all means, is that the full source to any password protected VI is available, and it just takes some creative solutions to get access to it. NI has a few articles on these limitations. The more secure way to protect your IP is to remove block diagrams from the source, or build it into something like a Packed Project Library (PPL). This is more akin to a DLL where you have some binary built thing, but no source.
Having said all that I hope it is clear, getting access to the block diagram of a passworded VI is relatively easy. In fact there exists a website where you can upload a VI, and some PHP code will simply overwrite the password with a new known one. I am not a lawyer and I give no legal advice. But if a company was contracted to perform some work, and they then password protected their work, then I see no ethical reason why you shouldn't be able to overwrite the password and get access to the source. I don't want to link to this site, but feel free to PM me if you have a hard time finding it.
As for the memory leak issue. If you do get access to the source, try the binary search method, where you disable parts of the code and see if memory is stable, or still increases forever. If you are lucky you'll find some place where references are opened, but never closed.
@Darren wrote:
LabVIEW will clean up references that were opened by a subVI after the top-level VI that called it goes idle. The same is true for a dynamically called VI if you don't close its VI reference.
You haven't described the functionality of the password-protected subVI. Is it performing hardware operations? DLL calls? .NET or ActiveX methods? Many of these types of references do *not* participate in LabVIEW's auto-clean up reference behavior, which means you have to explicitly close the references when you're done using them, and if you don't, you'll have a reference leak. And there is no way (that I know of) to try to fix those reference leaks externally outside the VI.
This depends actually a little how the leak is generated. The .Net or ActiveX methods work on LabVIEW refnums. LabVIEW refnums are subject to auto-cleanup as soon as the top level hierarchy in which the refnum was created goes idle. So if the leak is created by forgetting to close such a refnum, asynchronous dynamic calls still would ensure that it is eventually collected.
But there are of course other possibilities to allocate memory. Sometimes .Net and ActiveX classes do internal allocations that could be shared with other classes. And they can't just be auto collected on class destruction since the class can't be sure that those objects aren't used anywhere else. You then have to call an explicit Dispose() method for that object before disposing the class object itself. For such cases the auto-cleanup of LabVIEW can't help, as it doesn't know about this special need to call a Dispose() (or whatever it is called by the developer) method before calling the object class destructor itself.
