Jump to content

Locked Libraries and VIs that do not close


Recommended Posts

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

 

Link to comment

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)...

Link to comment

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.

Link to comment

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  :beer_mug:  at the next LAVA BBQ)

 

Here are the projects:

Message System Client Example.zip

Message System Server Example.zip

 

Thanks!

 

-John

Link to comment

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.

Link to comment

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:

 

post-107-0-54171100-1365110075.png

 

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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  :beer_mug: Todd!

Link to comment

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 by todd
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.