Slowly increasing memory when LabVIEW project is open

[UliB]

Hello all,

I am running LabVIEW 2013, Version 13.0.1f2 on Win7 64bit. I have TSVN Toolkit 1.8.2.22 from Viewpoint System installed.

When I open my project, I see LabVIEW memory slowly increasing, about 20MBytes per hour. I did not start any VI and I did not open any VI, I just opened the project!

I looked at it with process explorer from sysinternals and I see LabVIEW is executing cmd.exe and svn.exe about every 10 seconds. This equals the auto-refresh setting from TSVN toolkit. After every call to cmd.exe the memory increases.

When I call a TSVN command from toolbar (repro-browser, revision log, ...) memory increases.

Does anyone have seen this behavior too? Can someone confirm my seeings?

UliB

[EricLM]

Hi UliB,

I am running the exact same configuration as you and I do not see the same results. I have had a project with 200 VIs open and idle for about 4 hours now and have seen 0 increase in LabVIEW's memory usage. I realize that 200 VIs is not a lot, but it happened to be the project that I had opened when I saw your post and I work with significantly larger projects on a daily basis and do not see this. For reference, my auto-refresh is set at 5 sec.

You are correct that every time the toolkit needs to get status information, it makes (many) calls to svn.exe.

Can you provide some more information about your project? Like how many VIs? Is it possible that you would be able to share the project with me?

I would still like to hear from other users if they can replicate this behavior. I had one other report of this last year, but it never went anywhere because I could never replicate it on my machine or get anyone else here to replicate it and the person who reported it could not share their project with me.

Thanks

Eric

[UliB]

Hello Eric,

thank you for your time developing TSVN toolkit and for looking into my issue.

My project has two FPGA targets, ~700 VIs and ~150 ctls in 28 lvlibs and 10 lvclasses (not counting vi.lib). Only 20 VIs are FPGA VIs.

I noticed the increasing memory when I was working on and running a part of my application for about 8 hours and LabVIEW reported a "Not enough memory to complete this operation" message (Task manager showed 1.2GByte RAM for LabVIEW). Then I started looking at my application with "Performance and Memory ..." and Desktop Execution Trace Toolkit but did not find increasing memory allocations or reference leaks in my VIs. Then I noticed the open project is all it needs.

I saw this issue on two computers (my desktop PC and a NI PXI-8119 Controller).

Sharing the project ... . I'm not sure if I am allowed to. I will look at other, smaller projects if this issue is happening or if I can reduce the project and share a part with you.

Thanks

Uli

[UliB]

Hello Eric,

some more information.

I opened a small project under source code control. Same behavior. Memory is slowly increasing. If I stop "auto-refresh", then memory stays. If I call "revision log" or "check for modifications" from toolbar, then memory increases. If I call "repro-browser", then memory stays!? If I restart "auto-refresh", then memory continues increasing.

So I created a new, blank and unsaved project. Same behavior. I see memory increasing every call to svn, altough this project has no connection to source code control.

I opend my projects in LabVIEW2014 and did not see this behavior.

Maybe I should try reinstalling TSVN Toolkit?

Uli

[UliB]

Hello Eric,

I tried deinstalling and reinstalling TSVN Toolkit, but no success.

I now set auto-refresh rate to 120, so the memory is increasing more slowly.

I recognized two more things which I think are not OK.

- In my toolbar there is no entry for VI Dashboard

- Some of my VIs under SSC have no overlay icon in project explorer. Most overlays are OK, but in some virtual folders or classes the overlay icons only apper when I call a SVN command (e.g. update).

I read about VI Dashboard in the user guide for TSVN toolkit 1.7. Is it still in 1.8 available?

Uli

[Sam_Sharp]

It may be worth getting in touch with Viewpoint who make the TSVN toolkit. They may be able to assist in sorting this issue (to determine if it's a configuration/setup issue or if it's a problem with their toolkit).

This is a link to their site and there's a support link on the page here: http://www.viewpointusa.com/product/ni-labview-toolkits/tsvn-toolkit/

I think they've been on the forums so you could probably just link them to this thread to explain the problem.

[UliB]

Hello Sam_Sharp,

thank you for your message.

EricLM is the developer of the toolkit from viewpoint.

Uli

[EricLM]

Uli is correct. Contacting Viewpoint directly would go right to me.

As for the memory issue, I'm not sure what to say here because I cannot replicate this issue. I will keep trying some things, but I use the toolkit all day, every day and don't see a memory leak. I wonder if it's a wierd combination of toolkits or add-ons you have installed that maybe interfere in some way with the toolkit.

Virtual folders do not currently display overlays. It is something I would like to add in some day, but is a much more expensive operation than showing the overlays of auto-populating folders which represent a real folder on disk.

I would like to know more about the overlays within the virtual folders and classes. If you can capture a short screencast that shows this behavior, that would be very helpful. Are you sure those VIs are in SCC? Also, be aware that the class private data control is not an actual file, so it will never show an overlay.

We removed the VI Dashboard access from the toolbar to try to reduce the number of buttons there. You can access VI Dashboard through the file menu (in GSW and VI windows), the tools menu, and the QuickDrop shortcut ctrl+V.

Eric

[UliB]

Hello Eric,

thank you for clarifying VI Dashboard. I can confirm VI Dashboard is starting with QD Ctrl+V and there is an entry in VI file menu.

---

@EricLM wrote:
I would like to know more about the overlays within the virtual folders and classes. If you can capture a short screencast that shows this behavior, that would be very helpful. Are you sure those VIs are in SCC? Also, be aware that the class private data control is not an actual file, so it will never show an overlay.

---

I try to explain in detail with two screenshots.

In overlay1.png you see in project explorer SPS.lvlib which holds 4 virtual folders and SPS_Main.vi. These 4 virtual folders have a coresponding folder on disc as you can see in the upper windows explorer. SPS_Main.vi is in SCC, but I see no overlayin project explorer.

Look at PublicAPI folder in project explorer. There are two virtual folders without a corespondig folder on disc, just for grouping, and 5 VIs, which have no overlay icons, but in the lower windows explorer all VIs show an overlay icon.

If a do a right click on SPS_Main.vi and choose SVN Update, TortoiseSVN pops up with update dialog. When I close the dialog the modified overlay icon for SPS_Main.vi appears (as you can see in overlay2.png).

This happens in two or three lvlibs or classes in my project. And yes, I am aware that the private data control of a lvclass has no overlay icon, but the .lvclass file has.

I will see if I can record a screencast over the weekend, but I never did one before.

Uli

[EricLM]

Hi Uli,

One thing on the virtual folders: unless it is explicitly set as an auto-populating folder, it will not have an overaly.

As for the other behavior, what you might be seeing is a result of your slow update setting (I believe you set it at 120 sec) and possibly the large project. In short, the overlays will not update until that project item is displayed, so if you have a lot of project items showing or a slow update interval, after expanding a virtual folder the overlays will not update (or even show the overlay if they have not previously been displayed) until the next auto-update. If you generally work with a lot of items displayed in the project, then you may want to try collapsing some folders to speed up the update.

Most actions performed in the context menu will also trigger an overlay refresh for that item, so that is why you are seeing it refresh after doing an update.

I don't have any specific numbers, but my guess is that if you were working on a slow computer, or have a slow hard drive, having ~50 items displayed could start to slow down the update.

Eric