LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Build process hangs

Has anyone every seen a Build window like this?  Says "Initializing build.  This could take several minutes...", but also has the "Done" button available.  LabVIEW is not using any CPU in this state.  Hitting Done (or Explore) exits the dialog, but LabVIEW is completely frozen and must be hast-killed from the Windows Task Manager.

Build process stuck.png

 

This affects some, but not all, of my builds, so it must involve something about the application I'm building.

0 Kudos
Message 1 of 11
(4,698 Views)

Yes, I've been getting that in the past few weeks. Last night I left the build on and it had eventually completed after 3 hours (or something like that). 

I am using LV2015, both 32bit and 64bit versions.

--
Marko H

OptoFidelity - Enabling Smarter Future

Tampere - Espoo - Oulu - Cupertino - Redmond - Zhuhai

0 Kudos
Message 2 of 11
(3,751 Views)

Never saw this error before. But one of the building error occurred to me is because I didn't close the vi.

0 Kudos
Message 3 of 11
(3,744 Views)

I recently started hitting this same issue.


@drjdpowell wrote:

Has anyone every seen a Build window like this?  Says "Initializing build.  This could take several minutes...", but also has the "Done" button available.  LabVIEW is not using any CPU in this state.  Hitting Done (or Explore) exits the dialog, but LabVIEW is completely frozen and must be hast-killed from the Windows Task Manager.

Build process stuck.png

 

This affects some, but not all, of my builds, so it must involve something about the application I'm building.


One of the libraries I'm using is your SQLite code, building for Linux-RT.

As part of the setup, I'm generating dummy files for {extension-functions,sqlite3}{,_64}.dll (i.e. 4 files) in a Pre-Build step, since these previously failed the build if they didn't exist, but aren't actually required for a Linux-RT application (since there SQLite is loaded as a shared library from a system-installed version, if I recall correctly?)

 

Now those files are generated but nothing else appears in the build folder - not sure if this library is related but thought I'd mention it, since I'd guess you're also using it for some of your builds (5 years ago? hmm...)

 

I was using this without (other) issue until just this week though - the "Initializing..." with "Done" available and frozen behaviour you mentioned is new.

 

I'll try waiting as Marko suggested.

Did you find any other causes or solutions?


GCentral
0 Kudos
Message 4 of 11
(1,966 Views)

I'm afraid I have no memory of this from 5 years ago.  I must have fixed it somehow, as I haven't had this specific issue since then.  

0 Kudos
Message 5 of 11
(1,939 Views)

The times I have seen that I traced it back to a developer issue where I "inspected " the build output and realized I had stuffed a dependency in the wrong output location then fixed the spec and attempted to rebuild without cleaning the build output folder.

 

My guess is that the app builder does not really rebuild anything that does not need rebuilding because it sees the object exists somewhere and can get very confused when it exists in a recursive location but can't see it at the desired location so it hangs.

 

The obvious workaround is to never make a mistake then try to fix it.  

 

Yes, building to a clean output location will always take longer than rebuilding.  But, if the change is non-trivial or results in a dependency move. Clean first!

 

NI never tests for every mistake developers can make.  Whereas I, OTOH, have made many more mistakes than NI accounts for. 


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 11
(1,919 Views)

You could try to delete build destination directiry. It helped me many times when build gave strange outputs or hanged

0 Kudos
Message 7 of 11
(1,882 Views)

@JÞB wrote:

Yes, building to a clean output location will always take longer than rebuilding.  But, if the change is non-trivial or results in a dependency move. Clean first!


This was one of the first things I tried (and then the favourite clear compiled cache dialog).

Unfortunately it doesn't seem to help.

 

Diagram Disabling some bits has gotten me builds working - I'm not sure if the problem is a valid objection to invalid code, or an invalid objection to corrupted source, but it at least narrows the range of potential fixes.

 


@JÞB wrote:

The times I have seen that I traced it back to a developer issue where I "inspected " the build output and realized I had stuffed a dependency in the wrong output location then fixed the spec and attempted to rebuild without cleaning the build output folder.

 

My guess is that the app builder does not really rebuild anything that does not need rebuilding because it sees the object exists somewhere and can get very confused when it exists in a recursive location but can't see it at the desired location so it hangs.


Hmm, interesting. Will try see if there's something like this going on... Doesn't sound completely out of the question.


GCentral
0 Kudos
Message 8 of 11
(1,875 Views)

According to prophecy,  the first thing the app builder does is attempt to create a source distribution with all the VI properties reset to those in the build spec (debug disabled, typedefs disconnected, project library members removed, FP, BDs gone, etc...) 

 

A long hang here COULD indicate a project dependency in a long search path that probably should have been moved into the project.  A hang might also be due to exactly how the source is saved in the temporary location.  Specific implementations are not documented and are therefore subject to improvement. 

 

A Build Error 1502  can occur if something like a method is used that requires the BD or FP to be in memory or a weak link exists(e.g. an FPGA bit file reference) 

 

So my workflow is:

  • Floss project
  • Ensure all build specs are ordered
  • Clean all build specs
  • Save all this project
  • Build all

My hair may be going grey but, I still have a thick head of hair and don't find myself pulling it out in frustration. 


"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 11
(1,863 Views)

As the Champion of Channel Wires, I regret to say that if you (ab)use them as much as I do, you may eventually run into an Infinite Build.  I use Messenger Channels a lot (for Channel Message Handlers -- CMH instead of QMH), and I suspect changing the "State" component, defined as an Enum that has a dedicated TypeDef (as does the Message Type, a cluster of State + Data, a variant) can provoke this "infinite hang".

 

In this case, the "fix" (once you realize the problem) is simple.  Go find the "ChannelInstances" folder (on my PC, and probably yours, it is located in "Documents\LabVIEW Data\2019(32-bit)\ExtraVILib".  Choose the "grandparent" folder according to the Version of LabVIEW you are using.  The ChannelInstances folder can be safely deleted -- when you go to do the Build, LabVIEW will simply re-create all of the Channel routines you need in a new ChannelInstances folder as part of the Build process (which will run so much faster ...).

 

Bob Schor

Message 10 of 11
(1,848 Views)