Application builder fails with "File Not Found"

[lyricist]

Hi Folks,

I am trying to build a very large application which is based on GOOP2 classes. We have about 250 classes which are all included in the lvproj as dynamic VIs. The project definition puts just the top-level VI plus 2 classes in the executable and then all other classes go to the support directory. The fact that this is GOOP2 is probably immaterial since these are just basically groups of VIs... nothing special... just lots and lots of them.

Up until our previous code release the project built OK under LV 8.2.1. However our latest version (which only adds 4 classes and a few minor code changes) fails in 8.2.1 with a "Memory Full" error. In an attempt to move forward, I have built also in LV 8.5 which again builds OK up to the last source release but fails with the new version, this time with a "File not found" error.

Also, when it does fail, LV typically crashed (both in 8.2.1 and 8.5) and when I restart LV it goes through the "investigate error" dialog. The errors logges are always the same... "DWarn: You filled the image table" with the error at: //labview/branches/Jupiter/dev/source/manager/image.cpp#45. This may be a red herring but it does happen consistently.

My current suspicion is that there's a hard upper limit fo the number of VIs that can be declared as "Dynamic, always include". Is this possible?

Any suggestions would be very welocome as this is a complete show-stopper for us.

[gmart]

This issue sounds very similar to the one in this post - https://forums.ni.com/t5/LabVIEW/Application-Builder-Crash-drawmgr-cpp-line-3570-when-building/m-p/6...

[lyricist]

Hi George,

I'll give that a go. Do you think this could be the cause of both the "Memory full" and the "File not found" errors too?

-- Netta

[gmart]

This should fix the "Memory full" in 8.5 (Possibly in 8.2, but I believe the memory full error there could also be caused by something else). As far as the "file not found", check any library files to see if they link to any missing files. Since you said the file not found error started after adding four more class files, it may narrow the search down.

[lyricist]

Hi George,

The "Memory Full" only happens in 8.2.1

As for the "File not found" (which inly happens in LV8.5), I am 99.9% confident that the new classes do not link to any missing file. They are trivial classes. In fact it's only when I add the last 2 classes which cause the error. I first suspected that there was something wrong with my classes so I removed them and tried adding a brand new class (no additional methods implemented) just to see if it was some kind of upper limit I was hitting... and indeed this also failed in the same way. I am now trying another build where I remove two existing classes (which I know build ok) and add in the two new ones which were causing the failure... I will let you know how that goes once the build is done. As I mentioned, I fear we are up against some hard upper limit of the number of VIs which can be declared as "dynamic, always include"... Is this possible?

There also seemed to be a pattern where I build the project once and it fails with "File not found" and if i try to build it again (no changes) it then builds ok. This has worked up until the last two classes were added whereby no number of rebuild attempts have produced a successful build. Could this have anything to do with it?

So I guess one thing which would be helpful to understand is what conditions (other than a genuinely missing file) could result in a "File Not Found" error... especially when it doesn't tell me which file it is it thinks it can't find?

[gmart]

I am not aware of a limitation to a maximum number of files allowed. One thing I found was that there was a reference to problems in LV 8.5 when building a VI that has a static VI reference to itself. The error that was being returned looked like this:

"LabVIEW cannot find a file that is a dependency of a Startup, Exported, or Always Included VI.

File Not Found: .

The missing file might be referenced by one of the libraries included in the build or by the file - test.vi. To fix this issue:"

There should be a reported file but in this case, an empty value is returned. You can try doing a find on any Static VI References and seeing if this condition exists.

[lyricist]

Hi George,

Your feedback so far is much appreciated... The error you mention above is different from the error I'm getting though. The one I get is as follows:

Error 7 occurred at Invoke Node in AB_Source_VI.lvclass:Close_Reference.vi->AB_Build.lvclass:Copy_Files.vi->AB_Application.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW:  File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Linux. Verify that the path is correct using the command prompt or file explorer.
=========================
NI-488:  Nonexistent GPIB interface.

Method Name: Save:Target Instrument

Any clues what may cause this?

I have just finished the build with the two new classes included and two other classes removed and it built OK which is further confirms that my code is actually ok an continues to back up the upper limit hypothesis. I have now reinstated the two original classes and am trying the build again (so this would be a full set) and if the upper limit is true then I'd expect this to fail... I'll let you know the results.

[lyricist]

Well.. that build did indeed fail (and I tried it twice shutting down in between just in case).

Also, My 8.2.1 build has also finally finished (it's quite a lot slower than 8.5) and the Memory full still happens despite me having set the GDI objects to max 😞

[gmart]

I found this Knowledge Base about the memory problem in 8.2 - http://digital.ni.com/public.nsf/allkb/CBEBDC184655FC8C8625724A00050854. 

Regarding the "File not found" problem, unfortunately I think we're at the point where we'd need to look at your app to try to understand what may be going on. Since you feel the size of the app is the issue, I wouldn't think the problem can be replicated outside of your setup. I would recommend contacting NI support and working with an Applications Engineer to help resolve your issue.

[lyricist]

Hi George,

Thanks again for following this up. As it happens I know this Knowledge Base entry well 😉 We hit this limit a while ago and I made the changes as recommended which did help us for a while but I guess we are now hitting a new limit. As I mentioned in my initial post, we are already only putting the top level VI plus 2 GOOP classes in the executable. All other VIs go into the support directory.

I  have now pruned down the GOOP classes to only explicitly list in the project those VIs which represent dynamic methods. Up until now I had all methods (just dropped the whole class LLB into the project). I've just written a little utility to strip out all the non-dynamic VIs and I'll let LabVIEW work out which others are needed. I'm running the build in both 8.2.1 and 8.5. Lets see if this makes any difference.