Labview 8.5 project crashes when searching for callers of missing lvlib

[Ray.R]

I have done a search and reviewed previously reported crashes with LV8.5, but did not find a match to what I'm seeing.

SYNOPSIS: When selecting Find > Callers, under the project Dependencies, LV crashes as shown in the image below.

I created a new project and "borrowed" some vi's from another project.  Disconnected all vi's from previous libraries and proceeded to develop code last night.  All seemed well.

This morning, as I opened the project to continue coding, it complained about a missing lvlib, the one items were "borrowed" from.  No big deal, I'll just look at the dependencies and find out which one I missed.  When doing the search, the program crashes immediately.  Repeated a number of times with the same result.  Verified system performance and memory useage, minimal change when opening the project or attempting to do the search.

I will attempt a workaround, but I am curious if others have seen this as well. 

I'll wait before reporting this as a "bug", until more info is gathered on this.. 

By the way, the original lvlib was NOT deleted, removed, moved, renamed as the error suggests..  LV actually knows where it is because it finds the directory when doing the search..  

I know the routine, "simply re-install LV8.5", but I'm trying to understand more of what's gooing on and how we can avoid this..  I remember LV8.2 was crashing a lot at the beginning, then for no apparent reason, it became stable, and now I can't remember the last time it crashed..  Do others observe the same thing?  LV gets more stable with time??  🙂 LOL!  A program with personality.  Will LV turn into HAL?  LOL!! 😄

Here's the picture:

Message Edited by JoeLabView on 02-13-2008 08:35 AM

[Ray.R]

Found the problem..  It was something I suspected, but it shouldn't cause LV to crash...

In case it helps someone else, here it is:

I included a folder that had existing VIs to it.  One of the VI, I did not want to include, so I changed the extention to ._vi_, which rendered it not a LV vi.   Unfortunately, working late with insufficient coffee, when adding the folder to the project, this one got added as well.  Since the naming convention "fit-in" with the others, I did not see it.  It was the only orphan VI that was still linked to the original library.  Deleting it from the project cleared the problem.

There are two things that puzzle me:

1. Why was Labview looking at properties of a file that had an unrecognized extention "._vi_"?  Was it bad luck using underscores? I should try with other extentions live ".abcdefg" 😉

2. Why did Labview crash and not throw a simple exception?  I mean, this was a relatively minor mistake from my part.  And yes I do understand that we cannot test for "everything"  🙂  This is why I added this thread to the Feb 2008 bug list.  Maybe as a reminder to test for these things 😄

RayR

[Jennifer_R]

Hi RayR,

I'm glad you found the problem.  Thanks for posting the resolution.  It sounds like you already reported this as a bug, correct?  Thank you for providing feedback! 

[Ben]

" It sounds like you already reported this as a bug, correct?  "

I did not rad anything from Ray to indicate this has been CAR'd yet. He did indicate that he linked it into our Bug-Threads.

Please check with your team leader and tell them that "BenNI said AE are supposed to file and post CAR's for bugs posted on the forums."

If your team leader indicates otherwise, have them e-mail me at

bar@dsautomation.com

and I'll get them in touch with someone who can clear up the confusion.

Ben

Message Edited by Ben on 02-15-2008 08:58 AM

[Ray.R]

Thanks Ben,

I just posted in the bug list, no CAR, yet.

Had lunch on Friday with a LV buddy (LV instructor).  He has reported a few similar bugs with the project explorer on LAVA, and with NI.  He's observed several flavors of bugs when using the explorer which causes LV to crash.  Especially related to the use of libraries ("importing" modules into an existing library, etc). 

Ben,  I'll continue this topic elsewhere, where it can be discussed in more specific terms. 😉

RayR

[Jennifer_R]

Thank you both for the clarification. 

Ray, I haven't been able to reproduce the crash here and wanted to verify the steps that were taken before filing the CAR.  Do you remember at what point the extension was changed to ._vi_?  Were any error logs generated? 

If I understand correctly, you:

1. Created a new project.

2. Added a new library.

3. Changed the file extension of an existing VI to ._vi_ outside of LabVIEW.

4. Added a folder of VIs to the new library. 

5. Disconnected all VIs except "._vi_" from the old library.

6. Received the "missing lvlib" error, attempted to find callers, and saw LabVIEW crash.

Please correct me if I misunderstood or missed anything.  Thanks!

[Ray.R]

Good morning Jennifer,

I'll try to re-create the events from memory. 

OS:  Win-XP Pro - SP2

1. Opened library of VI's from Agilent E4440A drivers.  Opened the "Tree.vi" to look at available vi's.  Copied (pasted) some of the vi's into a new folder.   This may be important: I deleted the folder that contained the original library.  (Actually, the zipped file was moved to a storage location).  This means LV has no idea where to find the original library.

2. Opened all freshly copied VI at the new folder location.  They all complained about not finding the .lvlib file.  Ignored the error and disconnected every vi from the library and saved them.  All except for one which was polymorphic and I didn't need it. I forgot to delete it at this time.

3.  Created a new folder (real) within the directory structure of an existing project which uses an lvlib. Moved the disconnected vi's into this folder.

4. Opened the project and added the folder to the project, thus creating the virtual folder and files that were in the folder.  All this was added to the library.

Note..  I can't remember the exact steps below, but they were something close to what I describe.

5. Cannot remember if I closed the project then opened it, but I do remember seeing a message complaining that one VI could not find the lvlib (the one from Agilent).

6. Looked into the folder and examined the saved date, which quickly led to the polymorphic VI that was still part of the original library.  Since I was not sure if I wanted to use it later, I simply changed the extention from .vi to ._vi_.

7.  Did some work, saved everything. Closed the project..

8. Opened the project and got an error message about a missing .lvlib.  Again looking for the original Agilent lib. Remember that I had deleted the original library, it's folder, etc. (step 1).

9. Everytime I would open the project, I would get the error message.  I ignore it and continue working.  Since I don't like errors ;), I looked at the dependencies to find out what I missed. At this time, the file with the ._vi_ extension was still in the folder.  I had forgotten about it and didn't realize that LV would pick it up.

10. In the dependencies tree, I right-clicked the error message and selected "Find>Callers", as shown in the attached image of the original post. Got the crash message.  I repeated this 4 times.  Rebooted the PC, and repeated it twice. All the same result >>  Crash.   I may have saved a copy of the "crash" report, although I doubt it...  I didn't bother sending the report to MS; because, well, I don't have much credibility over what those guys do at MS.

11. Looked at the folder to go through every VI to find out which one was still connected to the library.  None of them were.

12.  Noticed the ._vi_, and figured there would be no harm to delete it.  Deleted it.  It resolved the dependencies, thus no more error, no more crash. 🙂

I am actually surprised that LV project also looks into non-DOTvi files for dependencies.  I imagined that it would ignore anything non-Labview known extentions.  This is definitely good to know.  However, the crash was a bit unexpected.

I will look for error logs.  If I have time, I may try to repeat this on my PC and send logs.  It will have to wait until I finish my surrent project (client / revenue) 🙂

Hope the above helps.

RayR

[Ray.R]

Hi Jennifer,

I did not find any Windows error logs.  I remember looking at the crash report contents, but did not save it.

Labview did not generate any errors / logs when this occurred.

Sorry.

RayR

[Jennifer_R]

Hi RayR,

Thank you for the additional information.  This was reported to R&D (# 94712) for further investigation.  Thanks again!

[Ray.R]

Thanks Jennifer

🙂