Bert posted ;
"
I was trying to determine if there was an actual memory leak when opening and closing ports, as this test will be run 50-100 times a day (opening two ports and closing them per run). 50-100 times shouldn't be enough to cause errors even with a memory leak but I'd like to know for future program use if it's a potential problem.
"
I do not think of it as a memory leak because I feel that term is intended to speak of memory that goes away with no explanation of were it went or how to get it back.
It is more a matter of understanding the environment that our LV applications run in.
I will not commence to hand waving since my knowledge of the OS stopped about the same time as Window NT was invented.
When we "open" a connection to a VISA resource (as well as many other similar operations), we are asking the environment (PAL?) to prepare a method for us to interact with the hardware (for example). Hardware is owned by the OS. We have no direct access to it without the OS providing such access.
The access is implemented using small blocks of memory that identify what type of access it is (DB, Hardware, etc) and the handles/pointers needed for the OS to understand the nature of the request or operation.
Let us step back into the way-back machine when the term "blue screen of death" was something that developers encountered on a regular basis. Those Blue Screens of death were very often "memory access violations". Access violation happen when the CPU attempt to access memory that it does not have the privledges to access (example Kernel mode is required to map memory) or is not mapped to the process.
I modern OS's the Blue Screen of death do happen as often as they used to. I suspect this is because resources like a VISA session when closed are simply "marked closed" waiting to be removed. BUt the "marking" as closed does not removed the pointer/handle to the data structure but only set a bit or some such.
Using the approach of "marking" instead of removing allows the LV environment to cover for some of our mistakes that result from the data flow paradigm coding what we drew and not what we intended.
Imagine someone opening a VISA session branching the session wire writing then closing in one branch then trying to read in another branch of the wire. If the VISA close actually unmapped the resource, the read after the close would be pointing at a invalid data structure dogs and cats living together and blue screen of death.
But by simply marking the session as closed, the late Read can unmark the session as closed and use it as if it was never closed. No Blue Screen of Death.
Done with the hand waving!
A few years ago I wrote a quick VI that did nothing but "open, read, then close" in a loop with no timer slowing it down and let it run over the week-end. On Monday morning I noticed the VI had more memory allocated to it. When I stopped the VI and it went idle, the memory foot print (Task Manager) went down.
I walked away from that experiment with the impression that there was a very small (in the old days 1K was not small!) amount of memory that was associated with each "Open".
Bottom Line:
There is memory associated with each open. Not a lot but it is there. If we are writing a cRIO app that has to run for years without a reboot, then we have to be aware that repeated open and closes will kill your memory eventually.
Form most application that are started run for a few days and then stopped, this entire post and point can be ignored.
That is my story and I am going to stick with it!
Ben
