VI Metric.Dat​aSize Property Error 1000 during execution

Question

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

Answer 1

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
Attachments:
Circular Buffer (Strings).vi ‏14 KB