Locked Libraries and VIs that do not close

[John Lokanis]

I have been seeing some weird behavior and was wondering if this is a known issue or if I have discovered something new.

I have two projects that share several libraries and classes.  One is a client application and one is a server.  In order to test my code, I need to open both projects at the same time and run the main VIs.  When I open the projects, the common libraries and classes are locked and I cannot edit them.  So far, this appears to be normal.  Where it gets strange is when I close one of the projects.  If I have run the VIs to test something and then stopped them, closing the owning project of one of the main VIs DOES NOT cause the VI to also close.  The correct project name is still indicated in the VIs window (lower left) and the project is clearly closed but the VI is still hanging around.  The second thing that is weird is the common libraries and classes remain locked. Even closing the other project and returning the to the start-up screen does not correct this.  The only way to edit those files again is to close LV completely and then reopen it.

This is getting a bit tiring and I am just starting to develop this project.  I am working with LV2012f3 but have not yet tested this in the 2013 beta.  (I really do not want to port the whole project over at this time).

 

Any thoughts?  Anyone else seen this?  I checked the known issues link and did not see anything related.

 

http://www.ni.com/white-paper/13993/en

 

thanks,

 

-John

 

[LogMAN]

I've encountered the same behaviour in LabVIEW 2011 and previous, where two projects would lock common libraries (which makes oviously sence). However I would swear that closing both projects and returning to the Getting Startet window will unlock everything (unless some VI is for some reason still running in the background). I didn't use LabVIEW 2012+ up till now, so I can't tell if there have been any changes related.

 

Did you check for a change in the behaviour if you close the projects in a specific order?

- open 1, open 2, close 1, close 2 -> Still locked?

- open 1, open 2, close 2, close 1 -> Still locked?

 

My guess is that LabVIEW does not update the locked status for common libraries in order to prevent re-checking for all libraries (which is like a reload)...

[John Lokanis]

One thing I have noticed is the issue appears to only occur after I run the code in the two projects.  Part of the code does open an app reference connection to the other project so they can communicate (as if they were two EXEs on difference machines).  I do cache that reference, but once the applications are stopped, I close that reference.  Even if I did not close the reference, it should get cleaned up when the VI stops.  And it certainly should clean up if the VIs and the projects are closed completely.  I am not spawning some daemon to maintain the references.

Seem like this might be a bug in the garbage collection routines.

[MikaelH]

It could be that a reference has been opened in Project Provider Application Instance.

Are you using and Project Providers, such as G#, GDS?

[John Lokanis]

Nope.  Although I am hoping to get a copy of GDS approved soon. 

 

I can readily reproduce the behavior.  I am attaching two projects that can be used to repro it.  Simply open both projects at the same time, run the example VIs and press a few buttons to test the application.  Then close the UI window to stop the application.  Next verify that the class libraries in the projects are locked.  Next try closing the projects.  You will see that the VIs owned by the projects do not close. (first strange effect).  Close those VIs manually and return to the start-up screen.  Open one of the projects again and verify that the class libraries are still locked.  Close LabVIEW and restart it.  Open the same project again and verify the class libraries are unlocked.

 

I would appreciate anyone who can verify what I am seeing.  I would be greatly indebted of you can tell me what I am doing to cause it! (ie: I will buy you a    at the next LAVA BBQ)

 

Here are the projects:

Message System Client Example.zip

Message System Server Example.zip

 

Thanks!

 

-John

[MikaelH]

I tried it the two projects and as soon as I run the Server Example all classes becomes locked as expected in that projects

I then Run the Client-Server Examples and all classes gets locked in that Project just like it should. I did press some buttons on the client, and then closed the Client-Server VI, and all classes got unlocked.

Then I close the Server Example VI and all classes in that project also got unlocked.

So I can’t reproduce your problem, sorry.

[John Lokanis]

Bummer.  I don't even need to press any buttons.  Just by running the example VIs and then stopping them, all classes are locked and remain locked.  Guess I need to try this on a different machine.

[todd]

They don't lock, here. (One reuse VI was missing, by the way.) But when I close the projects, the example VIs don't close.

I'm getting an error when closing the client:

 

 

I ran the 2013 DETT on it. There are two queue ref leaks and four VI leaks, but only when I manually stop the server.

[John Lokanis]

Here is the missing reuse VI:

Append info on error.vi

 

Run the server first and then run the client.  When you close the client UI it sends the server a message to stop so everything should stop without error.

 

I have not tried the DETT yet, but I should be closing all the refs on a proper shutdown.

[John Lokanis]

Ok, I just tried the 2013 DETT and the ref leaks are not real.  The Destroy code at the end of the project cleans up those refs.  Weird that the DETT cannot see that.  Seems like if your refs do not get closed in a normal dataflow then the DETT cannot tell they get closed.  By design or a bug?

 

I also tried it on a different machine.  I was not able to repro the issue yet, but it also wanted to save 24 VIs that it claimed had changed (exact same LV version, exact same file system layout).

 

One note: to get the app to work, you need to change your VI Server port to 3364.

[todd]

That VI matches the guess I made.

Yes, I tried server-first and client-first.

Turns out it was the server port. I have 2012 on 3365. Yours must be 3364.

 

DETT reports a project reference leak reported in Get Remote Application Reference.vi, and an Application Reference Leak.

 

Ah, you ran it. I have LV2011 on 3364 and 2010 on 3363.

[John Lokanis]

Any idea why DETT cannot keep track of the ref numbers?  I have code that closes the refs those VIs open when the app shuts down.  Just because I store the refs in a variant for awhile seems to confuse DETT.  Makes it kinda useless to me.

[todd]

I got one of the project ref leaks to go away by fiddling with: Get Remote Application Reference.vi

 

You can type-cast a ref to I32, then format into hex string and feed it to "Generate User-Defined Trace Event" on the BD.

"Get Remote Application Reference.vi" gets refs to both projects but only closes one.

[John Lokanis]

Weird. I will have to dig into that ref issue.

I checked out the source code on a different machine, recompiled it and then saved and checked it back in. I then went back to my main machine and synced to get the new version. Now I cannot repro the issue. So something got fixed but I will never know what I suppose.

[John Lokanis]

Found the leaks. One was a DVR I was disposing of in two different possible places but not closing it in one of those places. The other was I needed to close the array of project refs I got from the App:Project.Projects[] property. Kinda surprised that I needed to close that one. Looks like a static value to me. Shows you never can tell what is safe to close/not close... Still have no idea why the lock was going on. I wonder if it could be related to the ref closing issue? Seems unlikely.

Either way, I owe you a   Todd!

[todd]

Not sure it helps you, but I noticed:

When I closed those two projects, the LV icon was still in the taskbar.

I opened another project and happened to view the class hierarchy.

The Server and Client projects are still there, and PN App Project.Projects still lists Client and Servers projects.

 

Heh - crossed posts, again. I admit to occasionally being beer-motivated.

Edited April 5, 2013 by todd

[John Lokanis]

The Server and Client projects are still there, and PN App Project.Projects still lists Client and Servers projects.

 

That sounds like a real bug to me.  I will try to repro it.

[John Lokanis]

OK.  Confirmed the bug where the projects show up in the class hierarchy even when closed.  The other side effect of this is the VIs do not close when the project is closed.  Still not sure what causes this since it does not happen every time.