Interpreting lvlog.txt - build failing for unknown reasons

[Connor.Prior]

Hi!

I work on a large (4000+ VIs, 1.6 GB repository) LabVIEW program. I've just finished working on a new feature, and all of the sudden the code won't build anymore, always failing with this error:

 

"Error 1 occurred at An error occurred while saving the following file:

C:\Program Files (x86)\National Instruments\LabVIEW 2019\vi.lib\registry\registry.llb\Registry refnum.ctl

Click the link below to visit the Application Builder support page. Use the following information as a reference:

Error 42 occurred at AB_Source_VI.lvclass:Close_Reference.vi -> AB_Build.lvclass:Save.vi

Possible reason(s):

LabVIEW: (Hex 0x2A) Generic error.

Possible reason(s):

LabVIEW: (Hex 0x1) An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.

=======

Command requires GPIB Controller to be Controller-In-Charge."

 

The feature resulted in changes to several widely used typedefs, and an update to one of our core VIPM packages (one we make ourselves).

The code runs fine from IDE, and nothing shows up as broken in the project. I've run mass compiles a few times, which found some broken VIs that were removed from the project but not deleted from the repository, so I removed those. It also found a few "Insane Objects", most of which I have now removed. The mass compile output gets smaller each time, but the error code on subsequent builds never changes.

I've been trying to read the "LVInternalReports" that are created for each failed build, but I'm struggling to interpret some of its contents. In the lvlog.txt file of the latest build, I see several <DEBUG_OUTPUT> sections with DWarn lines that seem relevant. Here is one example:

 

"<DEBUG_OUTPUT>
2022-09-15 1:03:56.779 PM
DWarn 0xF481EB8C: error returned from SaveObjectData: 1 image {HeapClass=FPHP,UID=12,DPId=9,o=0x9db4fe00}
d:\builds\penguin\labview\branches\2019\dev\source\panel\savedata.cpp(634) : DWarn 0xF481EB8C: error returned from SaveObjectData: 1 image {HeapClass=FPHP,UID=12,DPId=9,o=0x9db4fe00}
minidump id: f47da8ab-45aa-4102-ba6b-3f32f5b84f42
$Id: //labview/branches/2019/dev/source/panel/savedata.cpp#4 $"

 

Is there a way to trace what this is referring to? I assume if this refers to a particular VI it will help me track down the issue, but I don't know what these hexadecimal codes refer to.

If anyone has suggestions for other ways to diagnose the build failure it would be greatly appreciated.

[hooovahh]

Yeah these suck sorry.  So you can start by clearing the compile cache and trying again.  This is in the Tools >> Advanced menu.  Then close and reopen everything.  It will take a while as it needs to compile all the code again.  Then you can try to build again.  Another thing you can try is to turn on the extra build details by adding NI_Appbuilder_logging = True in your LabVIEW.ini file.  This will make a text file along side your project file with details about the build.  It can be useful, but I've never had it tell me anything that helped with a build process.  If you do ever get it working you can remove this line from the config, it will probably make the build take longer since it generates that log as it builds.

I had a build that worked fine then it started getting harder and harder to build, needing to clear the compile cache a few times and try over and over.  Eventually I went to LabVIEW 64 bit and that issue went away.  That may solve one of your problems and create others.

[Connor.Prior]

Thanks for the suggestions, but unfortunately I'm getting the same behaviour after the cache clear, and I'm not getting anything useful out of the build log either.

[Neil Pate]

Sorry to hear about your troubles, this does happen.

One thing worth checking (as this has bit me many times) is dead/broken/old code in Diagram Disable Structures. Symptoms are like you noticed, running in the IDE is fine, but often the builder will just not cope. Often the dead code in a DDS is old and contains invalid enums or old versions of classes etc. Really funky things seem to happen.

[LogMAN]

16 hours ago, Connor.Prior said:

Error 1 occurred at An error occurred while saving the following file:

C:\Program Files (x86)\National Instruments\LabVIEW 2019\vi.lib\registry\registry.llb\Registry refnum.ctl

Click the link below to visit the Application Builder support page. Use the following information as a reference:

Error 42 occurred at AB_Source_VI.lvclass:Close_Reference.vi -> AB_Build.lvclass:Save.vi

Possible reason(s):

LabVIEW: (Hex 0x2A) Generic error.

Possible reason(s):

LabVIEW: (Hex 0x1) An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.

=======

Command requires GPIB Controller to be Controller-In-Charge.

This error happens when one of the files exceeds the maximum path length of 256 characters on Windows. While the file path can be short enough in your source repository, it might exceed the maximum path length during build.

Find attached a VI that extracts the longest path in a folder. Point it to the working directory of your project and see how long the longest path is.

Find Longest Path.vi

Edited September 16, 2022 by LogMAN

[Connor.Prior]

17 hours ago, Neil Pate said:

Sorry to hear about your troubles, this does happen.

One thing worth checking (as this has bit me many times) is dead/broken/old code in Diagram Disable Structures. Symptoms are like you noticed, running in the IDE is fine, but often the builder will just not cope. Often the dead code in a DDS is old and contains invalid enums or old versions of classes etc. Really funky things seem to happen.

I did have a decent amount of broken code in diagram disable structures, but unfortunately removing them had no effect.

2 hours ago, LogMAN said:

This error happens when one of the files exceeds the maximum path length of 256 characters on Windows. While the file path can be short enough in your source repository, it might exceed the maximum path length during build.

Find attached a VI that extracts the longest path in a folder. Point it to the working directory of your project and see how long the longest path is.

Find Longest Path.vi 9.63 kB · 4 downloads

The longest path length in my project is 136. When you say it might exceed the max length during the build, do you mean the build is the only time that limit is checked, or do you mean the paths may get longer during the build?

I also have several packages in the vi.lib folder, and the longest there is 217. Does the path limit affect these the same way?

[hooovahh]

7 minutes ago, Connor.Prior said:

I also have several packages in the vi.lib folder, and the longest there is 217. Does the path limit affect these the same way?

It can.  I believe the actual building will take place near the project in a hidden folder.  So if your project is in C:\Code\Repository\Project Name, then you will have a folder like C:\Code\Repository\Project Name\Hidden Folder\VI.lib\...  with all the code in it.  So the full path to the reuse and project can be an issue.  Shortening either is useful if that is the issue you are having.  This was a much bigger issue in the XP days, where people would have source code checked out in their user folder, which was C:\Documents and Settings\Users\User Name\My Documents

[LogMAN]

33 minutes ago, Connor.Prior said:

When you say it might exceed the max length during the build, do you mean the build is the only time that limit is checked, or do you mean the paths may get longer during the build?

The latter. Just like @hooovahh explained, the files are copied to a temporary location which can result in longer paths.

The output directory for your application determines the location of the temporary folder, which is actually just the name of the executable as a folder (i.e. "Application.exe" but it's a folder).

EDIT: Regarding vi.lib, these files also reside inside the "Application.exe" folder. Here is an example for JSONtext:
"C:\Code\Repository\builds\Untitled Project 1\My Application\Application.exe\1abvi3w\vi.lib\JDP Science\JSONtext\LVClass Serializer"

Here is an example of what it looks like during build.

Edited September 16, 2022 by LogMAN

[Connor.Prior]

I don't think paths are the issue here - builds from previous commits are passing with the same path lengths, and my build spec destination directory is C:\temp, so it's shorter than my repository location.

 

I have questions about something weird I found while working on this issue - does anything about the code change when you copy it to a new location?

I copied my directory to a new location to run some tests, but when I opened the project, I noticed several typedefs showing up as missing in the dependencies. They were all typedefs that I had recently deleted, but they weren't showing up as missing in the main project. In addition, when I clicked "why is this item in dependencies?" and found the offending VIs & typedefs, the dependencies were cleared as soon as I opened them, before I even resaved them to clear the changes. However, I found if I closed and re-opened the copied project the dependencies would reappear if I didn't re-save the VI the first time.

The appearance of these was somewhat inconsistent, but I found the most reliable way to get them to show up was to create a fresh project, and pull in individual modules from the fresh copy of the main directory.

I've cleared all such references that I can find, but the build is still failing. Does anyone know anything about why these appear, or how to reliably find them?

 

[LogMAN]

7 minutes ago, Connor.Prior said:

does anything about the code change when you copy it to a new location?

It depends. Sources files link to each other using relative paths, except for items in well-known locations (vi.lib, user.lib, instr.lib, etc.), which are referenced relative to their well-known location. As long as you don't change the relative location of files, nothing changes.

12 minutes ago, Connor.Prior said:

I copied my directory to a new location to run some tests, but when I opened the project, I noticed several typedefs showing up as missing in the dependencies. They were all typedefs that I had recently deleted, but they weren't showing up as missing in the main project. In addition, when I clicked "why is this item in dependencies?" and found the offending VIs & typedefs, the dependencies were cleared as soon as I opened them, before I even resaved them to clear the changes. However, I found if I closed and re-opened the copied project the dependencies would reappear if I didn't re-save the VI the first time.

This is a side-effect of how the dependency tree is generated. Instead of re-computing linkage information, LabVIEW relies on linkage information that is stored in a VI. So, if you change a typedef and don't apply (and save) all its callers, then the callers will have outdated type information, which can result in "ghost" dependencies. Clearing the compiled object cache and mass-compiling your project should generally fix these issues.

There are some exceptions where this doesn't work but let's just hope it doesn't apply here 🙂

[Rolf Kalbermatter]

2 hours ago, Connor.Prior said:

I have questions about something weird I found while working on this issue - does anything about the code change when you copy it to a new location?

Not the VI itself but if you have enabled to separate compiled code from the VI and since it is at a different path location, it is considered different to the original VI as far as the compile cache is concerned. And therefore since there is no compile cache entry for that VI yet, LabVIEW will recompile the VI.

Edited September 20, 2022 by Rolf Kalbermatter