LabVIEW
VI Metric.DataSize Property Error 1000 during execution
OK, maybe this will be an easy one for someone. Today I'm attempting to detect an apparent memory leak in a Windows executable on 8.6.1 that, despite my best efforts, is still causing the painfully ambiguous "Not enough memory to complete this operation" dialog to appear.
This is within an executable, so I thought the best way to tackle this would be to read the "Metric.DataSize" property off of suspect VIs during execution. I'm getting error 1000, which leads me to believe that I can't read the property while the VI in question is running. Is there some way around this? Is there an easier way that I've forgotten?
I saw a rather old post of a similar nature relating to 7.1, but the recommendation was to use the memory monitor example. I took a look at that example's code, but they're calling the same property without error handling.
Thanks a lot,
Jim
Hello Marti,
First of all, thanks for getting back to me. I did manage to track down the memory leak -- more on that soon enough -- but here are some answers to your questions:
First, I'd recommend trying to tackle this issue in the original VI. When you run the VI, do you get the same error?
If you're asking whether I see the error in the development environment, I haven't, unfortunately. However, I haven't run the VI for any extended period of time, either. Also, I don't know if I was clear on this: it's not really an error message in the traditional sense of a code and description. It's just a plain dialog that appears to be thrown by the runtime engine.
If not, can you monitor LabVIEW's usage in the Windows Task Manager, and see if it creeps up continuously?
I hadn't resorted to trying that just yet because I was hoping there was an easier (and more specific) way. The dialog I had seen was the plain one that the runtime engine seemed to have launched, so I figured it was a pretty safe bet that it was a memory leak. I could confirm this with task manager, though, if it's helpful.
If it does not, then you may not have a memory leak but be performing operations or copying large data arrays inadvertently. What is your VI doing? Are you ensuring to close all references at the end of your code?
In this case it's a "web viewer" application that receives data from a parent VI via a notifier and displays it for connected browsers. I'm also scanning some status strings and parsing out relevant information. I know it's within the web viewer VI because the parent VI hasn't changed and has run for weeks without any issue. (I only recently added the web viewer) I am downright paranoid about memory!
I close every reference every time and even use the "in place" structure every time I can.
Does the VI run for a bit or error out with the memory issue immediately?
It takes a while; usually an hour or two.
Please investigate into the original VI so we can continue troubleshooting. If this is isolated to the executable, it will be a little tougher to debug. Additionally, if you don't have the original VI, you will need to get it either way so that we can investigate the source of this issue.
Okay, as I said earlier, I think I've figured it out. I have a VI that writes to a string indicator by reference. I had a circular buffer for messages (it used the in place structure, too!) and I was updating the string indicator with the buffer contents. I'm almost certain that the circular buffer works properly because I've used it before without any issue. However, I think it had something to do with the manner in which I was updating that string by reference over and over again. I know, it sounds crazy because I've updated indicators by reference continuously before and had never had an issue. It's possible that I was also using my circular buffer in a different way than I was before. I could explain what I did differently to fix the issue, but it would be a couple more paragraphs. (I will if you want!) For the record, I was definitely closing the reference every time, too. In any case, I think the issue is solved, but if you're interested in additional information I'll try my best.
By the way, here's my circular buffer VI.
Again, Marti, thanks very much for your assistance.
Regards,
Jim
Hi Marti,
Ugh. It turns out that I didn't solve the issue after all. Over the weekend my executable popped up a bunch more of the ambiguous "not enough memory..." dialogs. I tried something else, however and made an important observation:
Considering that the issue hadn't shown up before I added the "web viewer" subVI and turned on the NI web server in my build, I strongly suspected that it had something to do with those components. When building my executable this time, I put a disable structure over everything in the web viewer VI to rule it out. I still left the NI web server turned on, however. My HTML file displays an automatically refreshing screenshot of the web viewer VI, so I turned down the timer interval so that it refreshes every half a second or so. (To reproduce the error as quickly as possible.)
I then observed the memory usage in Sysinternals' Process Explorer (like Task Manger except better and more detailed). When I navigate to the web page, thereby connecting to the NI webserver, the executable's memory usage immediately starts increasing by leaps and bounds. Something like a MB or two every five seconds! If I navigate away from the web page, the memory growth stops. (And never decreases! It's as if memory is never being deallocated)
Also of note, before I added the NI webserver and web viewer VI, this application had been running for months.
Any thoughts? Have you seen anything like this before? I'm going to continue my experiments in the meantime.
Kind regards,
Jim
Okay, I put together this proof of concept project that's made from a stripped down version of my code. It's a simple executable that hosts a snapshot page via Remote Panels / NI Webserver. There's nothing at all complex about it. I then ran the executable overnight with a browser connected. When I left to go home last night, the executable's memory usage was 19,744K. When I arrived this morning, its usage was a whopping 1,748,444K!
Is this a known issue? I know that this is LabVIEW 8.6.1 and that LabVIEW 2009 may have addressed this, so I guess my next step will be to run the same proof of concept on LabVIEW 2009.
Any thoughts? Have any of you run into this already?
Thanks,
Jim
The Chancenator wrote:Hi Jim,
Are you running the webserver in monitor mode or embedded mode? If you are doing monitor mode, try using the embedded mode. Let me know what this test yields.
Thanks,
Hi Marti,
I believe I'm using "monitor" mode. If understand correctly, this means I'm displaying a screenshot of the front panel rather than allowing users to take control of the front panel? (It's been a while since I've done this)
Thanks,
Jim
Marti, this is indeed monitor mode. I was modifying existing niwebserver.conf and HTTP files, so I hadn't run the web publishing tool in a while. (Running it refreshed my memory on the nomenclature)
I'm now testing the same proof of concept application in LabVIEW 2009, and in the last five minutes, the memory usage has gone from 21,928 K to 32,232 K. I'll keep you posted, but things aren't looking good at this rate.
If you'd like I can post the LabVIEW 2009 version as well.
