Labview crashing when building executable

[wiebe@CARYA]

---

@AdarshaPakala wrote:

After increasing virtual memory to 18GB+, the LabVIEW is not crashing but, I get this error now.

---

Increasing memory won't help a 32-bit application.

There's a limit to the memory 32-bit applications can allocate, and it's nowhere near 18 GBi.

[Andrey_Dmitriev]

I think, it makes no sense to increase the memory as long as you have 32-bit environment. On 64-bit OS you will get max 4GB, but not more.

So, one possible way is to migrate to 64-bit LabVIEW (if you can - you should have 64-bit versions of all toolkits used in your app as well as 64-bit versions of the DLLs, if applicable).

Another way is to split your application to smaller pieces and then compile these modules separately. For example, in my project I have 6577 SubVIs currently, but they splitted to many PlugIns, which compiled to *.llb, each one with own build spec.

[AdarshaPakala]

The application when running at peak data load and maximum modules loaded, never cross 3GB memory in development environment. Its tested for 10hrs(windows task manger monitoring and windows performance monitor logging)

Wondering why LabVIEW need more than 4GB while making an executable(building time).

[wiebe@CARYA]

---

@AdarshaPakala wrote:

Wondering why LabVIEW need more than 4GB while making an executable(building time).

---

It rarely does.

It feels to me something got corrupted. Could be anything, on a diagram, or a class's private data section, in the project...

If there's some weird circular dependency going on (infinite recursion), no amount of memory will be enough.

You can try to simply delete some class hierarchies. If you're lucky, it won't be too hard. Don't worry about keeping your code working, it's just to find out if a particular part of the code causes the problem. Do use SCC of course.

Of course, going back in SCC could help you identify when things went wrong...

[rolfk]

Actually, if LabVIEW comes ever close to a committed size of 3GB at runtime, as your comment could be interpreted like, you are constantly skidding at the edge of what a 32-bit process can do. Those 3/4GB are an absolute maximum size a 32 bit process can use. Due to memory fragmentation, which is unavoidable in every real world usage, the Windows kernel will usually be unable to satisfy new memory requests long before that limit is reached. Your process may only use 2GB of memory, but that remaining 1GB of memory is almost never a single continuous block and if your program then wants to process a 50M Sample array of double precision values( you will almost certainly run out of memory as Windows can’t find a single continuous block of 400MB anymore, to hand to LabVIEW.

Building an executable can have its own challenges if your application has deeply nested VI hierarchies with huge diagrams and all VIs set as reentrant! I would look at the maximum code complexity index of your more extended VIs.

[AdarshaPakala]

@wiebe@CARYA

It feels to me something got corrupted. Could be anything, on a diagram, or a class's private data section, in the project...

Can this be caught in a mass compile log files? any particular error tag to look for this error?

Deleting class and class hierarchies would be a very very complex process as there are lot of dynamic class object instances creation and typecasting which goes with code logic.

P.S: I can load and run the project without any error and the mass compile is always goes though successfully.

[wiebe@CARYA]

---

@AdarshaPakala wrote:

@wiebe@CARYA

It feels to me something got corrupted. Could be anything, on a diagram, or a class's private data section, in the project...

Can this be caught in a mass compile log files? any particular error tag to look for this error?

---

I'm not sure. I never mass compile.

---

@AdarshaPakala wrote:

Deleting class and class hierarchies would be a very very complex process as there are lot of dynamic class object instances creation and typecasting which goes with code logic.

---

It doesn't have to run, nor do anything useful; it only has to compile. It could still be complex, but if code gets broken, simply disable it so it can compile.

This is only a drill to find out if there's anything that makes LV crash. Once you find something, revert and try to fix the problem.

---

@AdarshaPakala wrote:

P.S: I can load and run the project without any error and the mass compile is always goes though successfully.

---

Yes, it's a pickle 😉...

You could try to clear class mutation history.

See the attached VI. Use at your own risk! Make sure you have your code in SCC or at least a solid backup!

If you have flattened classes in files, clearing the class mutation history will make that data invalid... 

[AdarshaPakala]

Thank you so much for the detailed reply!

I have cleared the class mutation history but it did not help.

[wiebe@CARYA]

---

@AdarshaPakala wrote:

Thank you so much for the detailed reply!

I have cleared the class mutation history but it did not help.

---

Can you go back in your SCC to see what changed when it stopped working?

Sometimes the class data gets corrupted in ways that can only be changed by editing the .lvclass's XML data.

However, I've never seen a build crash caused by this. It usually prevents the project from loading or opening the (or even any) class.

I'm running out of ideas...

[AdarshaPakala]

• Going back to previous versions and tracing the possible reason for build crash was not that fruitful for us as the last successful build was created an eight months back and we have so many versioning after that(code pushed by multiple developers). 
• Somehow we have convinced that it is the size of the project and LabVIEW is running out of memory while building.
• We have looked into the option of upgrading LabVIEW to 64bit and run it on 64bit Win10 OS, but we have a road block in this, we have used Hierarchical Waveform Storage (HWS) in our project which is not supported in LabVIEW 64 bit( HWS cant be replaced in our project easily due to the backward comparability issue).
• One of the other option we have right now is, stripping the project as much as possible by removing unused VIs from library and controls/indicators in the VIs
  • Is code inside the disabled structure add to the memory while building process?
  • What is the efficient method/trick to search and remove the unused VIs from library and controls/indicators in the VIs ?

Thank you!