guentermueller

Nice work, Bean.  Can I use this code in a commercial application?

I see a copyright note in the VI Documentation.  Is the code covered by a specific license?

But there is a note: it was verified that reentrant VIs use the same memory. Can run SubVI five times, then close the references of subVIs, then run another 5 times and you will see that more memory will not allocate...

Running the VI 5 times (I am always referring to the VI in the mode when it produces an array of strings) just uses a good amount of memory that you will not get back - but just can reuse by further calls to these reentrant instances.  So you cannot run another 5 instances of this VI in LabVIEW 32-bit - or do any other very memory consuming task that would have fit into memory before executing these reentrant VIs. Oops!

I am glad to hear that Mr Mike has announced a check of this behaviour and provided a CAR.

I don't want to insult you, but you are generally a text based programmer aren't you?  I say that because at least from my perspective I don't care what LabVIEW does with memory, but I've seen other text based developers get hung up on trying to understand the low level of what is going on.  The compiler is better equipped to do as it pleases, releasing and reallocating memory as it needs.  I trust the compiler until I see a reason not to (crashes, or run away memory).  I suggest you do the same, trust the compiler.  

 

You stated that memory is released properly when you close LabVIEW, and the memory is reused within the application when it needs to be so what is the problem?  Where is the bug?  If it doesn't release the memory then it must need it for a reason that I could not predict.  I do not see is as a bug, and I deal with very large amounts of data in the form of larger sized arrays of clusters of arrays all the time.

I cannot agree: The VI posted here (memoryusage_reference.VI) is a reentrant VI that you can easily use to fill the memory in use by LabVIEW - even placing a Request Deallocation in its BD does not help if this VI produces an array of strings.  With a 32-bit LabVIEW, you quite quickly get the famous "Not enough memory to complete this operation" message. Sole reason:  Request Deallocation rejected to properly clean up.  Although the documentation promises to do so.

To my opinon, this is a bug in LabVIEW and as I take from this thread, it is still living in LabVIEW 2013.

I feel encouraged to move code like this to a C/C++ DLL ...

How bad would it hurt if we said, "Nope... you can only have one event structure per VI." ?

One Event Structure per VI is the usual practice in all the code my colleagues and me produce.  There might be some VIs in our code that would break if LabVIEW came with that behaviour change.

the SP1 that is on the Update Service is supposed to include f1, did you download SP1 manually or use the auto update?

I did a manual download and did not experience the crash.  It seems that Muds just has a bad day ...

[...] $100USD is rather steep for a casual read, though.

Especially when considering that you get 277 pages of paper for the money. I do not know anyone who has read it, but I would expect topnotch information for that price.

I would use this approach. It is fast and reliable.