01-18-2006 05:51 AM
It IS the problem. LabVIEW before 7.0 always returned unique VI server references and therefore you had to close them explicitedly in order to avoid memory leaks. A general thum of rule for >= 7.0 is probably that properties returning owned references will be really static and don't need to be closed (but doing so anyhow does absolutely not hurt). The Owner reference however is not an owned reference of the VI object you access the property of so it is a unique reference and needs to be closed explicitedly.
@BJK wrote:
I can't remember exactly, but I think I was using LabVIEW 6.1 (now I am using 7.0).
Maybe that was the problem!!
01-18-2006 05:55 AM
I think that this statement is not entirely true. The "Snd Play Wave File.vi" will likely allocate a new Application reference everytime it is executed. As such it is most probably a bug but definitely an example of bad programming style.
@Dynamik wrote:
According to these rules, and in the case of my example, memory IS allocated by "Snd Play Wave File.vi", but only once - no matter how many times it's called. That memory is de-allocated when the Top-level VI finishes executing.
01-21-2006 04:02 AM
Cheers
rolfk wrote
... The "Snd Play Wave File.vi" will likely allocate a new Application reference everytime it is executed.
01-21-2006 04:36 AM
You are right I just did a small test and the local application reference seems to be always 0xFFFFFFFF in LabVIEW 7.1.
@Dynamik wrote:Hi Rolf,After reading your post, I modified the VI to pass-out the un-closed reference (cast to U32) to see whether reference would be unique on each iteration. The result is clear as mud! 0xFFFFFFFF is always returned... interesting, but not very helpful.
01-21-2006 04:30 PM - edited 01-21-2006 04:30 PM
rolfk wrote:
I think it is still a good idea to always close VI references and definitely explicitedly opened (Open .... function) ones.
Rolf Kalbermatter
I'm going to follow your advice about always closing references which I've explicitly "Open"ed. I guess most of the uncertainty is related to references not explicitly opened. Lately I've been working with databases (MS Access, SQL Server) and have come across yet another example (for which there's no help in LabVIEW)
The way it works is, one opens a Connection, then a Command, then specifies the command-text, then "Executes" the command. Execute returns a RecordSet reference - which I think should be closed - whether it's used or not.
exe.GIF (3 kb) |
Message Edited by Dynamik on 01-21-2006 04:36 PM
01-22-2006 05:34 AM - edited 01-22-2006 05:34 AM
This is ActiveX/COM and there is a strict rule. Always Release an object you receive from whatever after you do not need it anymore. Of course this may sound strange in terms of LabVIEW but COM objects maintain a refcount and deallocate themselves after that refcount reaches 0. Any method returning an object pointer is supposed to call that objects AddRef function which increments the refcount. LabVIEWs Close Reference function for ActiveX does mainly call the objects Release method, which decrements the refcount and then disposes of LabVIEW's internal refnum leaving the rest to the COM object itself.
@Dynamik wrote:
I'm going to follow your advice about always closing references which I've explicitly "Open"ed. I guess most of the uncertainty is related to references not explicitly opened. Lately I've been working with databases (MS Access, SQL Server) and have come across yet another example (for which there's no help in LabVIEW)
The way it works is, one opens a Connection, then a Command, then specifies the command-text, then "Executes" the command. Execute returns a RecordSet reference - which I think should be closed - whether it's used or not.
Message Edited by rolfk on 01-22-2006 12:48 PM
01-22-2006 06:34 PM
Hi Rolf,
5 Stars is insufficient payment for your last post, but that's all there are!
Instead of trying to "optimize" a diagram by trying to avoid Close Reference functions whenver possible and risking memory leaks either because you overlooked a certain refnum being dynamic or you upgrade to a newer LabVIEW version that happens to change the behaviour of a refnum from static to dynamic because NI had to fix a problem somewhere, it is much better to simply be consequent and always close any refnums properly once you are done with the object that this refnum refers to.
Just a small point: if the above quote refered only to ActiveX/COM, then this point was clearly made early in the thread - and more-so by your post. However, if this advice applies to all references then I must emphasize:
my interest in effectively handling references isn't so much for "optimization" as it is for clarity.
Knowing it's not effective to close every reference in Control[]s references allows for a cleaner diagram. (Cleaner-> easier to maintain -> more reliable.)
01-22-2006 11:33 PM
Hi Dynamik,
Not to completely beat this topic into the ground, but one of my style rules for people who wrote VIs for me a while back was to always close references, no matter what kind they were (see my previous post toward the beginning of the thread where I advocate this rule). It may take more space on the diagram to close references, but it gave me peace of mind knowing that all references were being closed...I would argue that the programs were more maintainable because we never had to go back over all the places in our code where references were being opened to see if closing them solved any problem we might have been encountering...this is because the references were always being closed regardless of what type they were.
-D
01-23-2006 12:35 AM - edited 01-23-2006 12:35 AM
Well,for ActiveX you MUST close all references and for VI server I recommend VERY STRONGLY to close all references independant how you got them. Performance wise a Close Reference on a static reference is a NOP and therefore optimized away by the LabVIEW compiler.
@Dynamik wrote:
Just a small point: if the above quote refered only to ActiveX/COM, then this point was clearly made early in the thread - and more-so by your post. However, if this advice applies to all references then I must emphasize:
my interest in effectively handling references isn't so much for "optimization" as it is for clarity.
Knowing it's not effective to close every reference in Control[]s references allows for a cleaner diagram. (Cleaner-> easier to maintain -> more reliable.)
Cheers!
Message Edited by rolfk on 01-23-2006 07:53 AM
01-23-2006 12:41 AM - edited 01-23-2006 12:41 AM
Message Edited by Dynamik on 01-23-2006 12:43 AM