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 post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites

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.

Link to post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites

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.

Link to post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites

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.

Link to post
Share on other sites

Join the conversation

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

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

  • Similar Content

    • By X___
      The title is made up, but explains what I have been experiencing for years, hoping that it would be fixed in the next version, but it never has, so I am starting to suspect nobody is caring or possibly maybe nobody even noticed it?
      Anyway, the symptoms are:
      when I drag a VI (from either a palette or from the icon of an open VI) into a target VI's diagram, I am frequently encountering this odd and annoying 🚫 symbol where my cursor is (it's not red and it is slanted the other way, but this is the closest emoji to the real thing I could find), instead of the "androgynous" cursor (a mix of ♀️and ♂️) which tells me that I am going to copy that object where the cursor is.
      I would move the cursor around, seeing a 🚫 wherever I go, until I would fleetingly grasp a cursor with the + index (the "androgynous" cursor) over some random location, and then, painstakingly try to go back to that region to find the sweet spot (pixel really) where I am able to drop the VI. Of course, once dropped on the diagram I can move the VI anywhere where I was forbidden to drop it during my initial attempts.
      That's got to be the most annoying bug in a graphical programming environment ever...
      Am I the only one to experience this?
      I am using 2019 SP1 64 bit, but that has been around for several versions already.
    • By Ryan Vallieu
      I have seemingly found an issue with the shipping example code for Nested Malleable VIs.  Another user has verified that he saw the same behavior in 2019.
       
      I am working through the examples and the presentation from NIWeek 2019.  In running the Lesson 2b code (C:\Program Files (x86)\National Instruments\LabVIEW 2019\examples\Malleable VIs\Nested Malleable VIs) I found the Equals.vi in the class was not being leveraged and the search failed.  When I went to my LabVIEW 2018 machine and ran the Lesson 2b.vi the code worked to find the element by correctly leveraging the in-class Equals.vi.
      One difference I see is that in the 2018 example the Equal.vi is in the example folder with the code, and in 2019 the Equal.vi has been moved to VI.lib - otherwise the code looks to be the same.  The Equals.vi code looks identical, and the calling VIM look identical.  I posted on the LabVIEW NI.com forum here: 
      https://forums.ni.com/t5/LabVIEW/LabVIEW-2019-Malleable-VIs-Shipping-Examples-Lesson-2b-Nested/m-p/3966044/highlight/false#M1129678
       
      I am trying to determine what may have broken or changed between the implementation in 2018 and 2019, visually the code looks the same.
    • By 0_o
      Hi,
      This is not specifically LabVIEW related:
      How do you organize important posts you read and want to save for the time of need?
      For example, I want to save an interesting post from Lavag/NI Forums or any other LV blog.
      This post might contain VIs and I would like to tag it in a way that will let me find it when it becomes relevant.
      I would like such a post to be saved locally like an RSS so that I'll get the new comments and won't depend on the site to keep the links alive.
      I see the veterans here keep track of all the new posts and even offer solutions by giving links to some old posts without having to search for them sometimes.
      Do I miss something? How do you organize it all? I hope to hear of some cool little RSS app that will let me search through the tagged vis and posts stored on my computer and not about some bookmark manager.
      Thanks in advance.
       
    • By GregFreeman
      I currently have a project that I am refactoring. There is a lot of coupling that is not sitting well with me due to typedefs belonging to a class, then getting bundled into another class which is then fired off as event data.
      Effectively, I have class A with a public typedef, then class B contains ClassA.typedef and then class B gets fired off in an event to class C to be handled. Class C now has a dependency on class A which is causing a lot of coupling I don't want.
      For my real world example I query a bunch of data from our MES, which results in a bunch of typedef controls on the connector panes of those VIs. Those typedefs belong to the MES class. I then want to bundle all that data into a TestConfig class and send that via an event to our Tester class. But, now our tester has a dependency on the MES.
      I see a few ways to handle this. First is move the typedefs currently in the MES class, to the TestConfig class. The MES VIs will now have the typedefs from the TestConfig class on their connector panes, but at least the dependency is the correct "direction." Or, I can move the typedefs out of classes all together, but then I am not sure the best way to organize them. Looking for how others have handled these sorts of dependencies.
       
    • By Voklaif
      Hello all,
      I am programming with LabVIEW for around 2 years and was recently stumbled upon LVOOP.
      I am required to write a communication protocol to work with a micro-controller, which later will be also used for ATP and debug purposes.
      I want to build the program "correctly" from the beginning so it will be maintainable and flexible to additions and changes.
      My natural way of building a program would have been a queued state machine, with several loops, each loop is in charge of a different module (one for GUI obviously), but as I stated in the beginning, I want to use LVOOP.
      Does anyone have a LVOOP project I can use as reference? I've searched online and found some nice examples, but they are small and teach you the basic stuff.
      For me it's important to see the how to use the project tree wisely, where to place the classes, see the managing loop and to learn as much as possible before I create one of my own.
      Thanks in advance,
      Voklaif
×
×
  • Create New...

Important Information

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