LabVIEW
Labview crashing when building executable
Solved!
Does this mean to say that you have an application, on which multiple developers are adding new features, and nobody has tried to build that beast in 8 months?
That would be the typical "By failing to plan, you are preparing to fail”
I see three possibilities where this could go wrong:
1) LabVIEW compiler problem
Either the memory consumption is to big or something in your build got corrupted.
- How many VIs are we talking about here?
- What's the typical code quality/feel? Neatly structured? Small self contained VIs? Or rather huge monster VIs that use huge stacked frames, globals, locals and other nasties?
- Does it use any of the "use on your own risk" techniques? That includes not only unofficial features through use of hidden ini tokens but also things like XControls, Packed Libraries, and similar.
- Have you cleared the compile cache?
- Have you recompiled the whole VI hierarchy?
2) Your LabVIEW installation got corrupted
- Did you try the build on other machines with the same version of LabVIEW and Toolkits?
3) Your program somewhere imports external code that doesn't like to be dynamically unloaded and reloaded. This could be ActiveX controls, .Net assemblies or good ol DLLs called through the Call Library Node.
And yes I had this sort of thing happen to me more than once. One specific DLL would crash every time I unloaded the project, without even running a single function. First technical support call to the supplier was "no there was no known problem". After I built a little test program in C that did nothing more than load the library and then free it again, and it consistently crashed too, and sending that test program to them, I got a fixed DLL within a week.
In terms of tackling this, I would probably first investigate for the possibility of number 3) then 2) and also clear the compiler cache and recompile the whole program. If none of that seems fruitful then things will be getting though for sure.
Next step would be to disable large code chunks to see, if the build problems are related to sheer code size or specific code junks that might trip something. Don't exclude the possibility that it is definitely something in the code that causes this. It is easy to try to blame LabVIEW but very unproductive and more often than not, actually simply deflective behavior.
@rolfk wrote:
- Does it use any of the "use on your own risk" techniques? That includes not only unofficial features through use of hidden ini tokens but also things like XControls, Packed Libraries, and similar.
Packed libraries? Aren't they considered the solution to similar things? Why would they be "on your own risk"?
@Yamaeda wrote:
@rolfk wrote:
- Does it use any of the "use on your own risk" techniques? That includes not only unofficial features through use of hidden ini tokens but also things like XControls, Packed Libraries, and similar.
Packed libraries? Aren't they considered the solution to similar things? Why would they be "on your own risk"?
They can be a good thing, if you absolutely know what you are doing. They also have a few rather serious shortcomings, especially if you want to use the code on more than one LabVIEW platform. That includes even 32-bit and 64-bit versions of LabVIEW on the same OS. And gets quadrupled if you plan on using them with realtime targets too.
But you don't have to believe me Other people have similar advice, among them the mighty Darren Nattinger 🙂
https://www.youtube.com/watch?v=HKcEYkksW_o
Technically a PPL is like a shared library: precompiled, packaged and ONLY for exactly one single binary platform. But a DLL is for the rest very loosely coupled with the calling application. The only things that can be relied upon are the library name, the exported symbols and the parameters of exported functions PPLs on the other hand are not only in a proprietary packed archive format but also integrate tightly with the calling LabVIEW process, which can have advantages but also can bite you in the butt in very unexpected and sometimes rather unpleasant ways.
And the developers of the PPL technology have stopped working on this feature as soon as it started to work, leaving many corner cases and less common use cases unhandled and outside in the cold.
@AdarshaPakala wrote:
- 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).
Please don't tell me there hasn't been a compileable version in 8 month, even if you didn't compile a version...
You're testing compilation, not proper functioning of the program.
@AdarshaPakala wrote:
- Somehow we have convinced that it is the size of the project and LabVIEW is running out of memory while building.
So, reduce the size of the project to test that theory...
I'm sure you can make the project compile without a lot of code.
Again, the program doesn't need to work, just compile.
@AdarshaPakala wrote:
- 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).
You can still remove, go to 64 bit, see if it compiles.
Also, you could consider a newer LabVIEW version. It's not unlikely this problem was fixed between LV16 and LV22.
@AdarshaPakala wrote:
- 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?
It costs memory while building, it doesn't end up in the executable.
@AdarshaPakala wrote:
- What is the efficient method/trick to search and remove the unused VIs from library and controls/indicators in the VIs ?
In the project you can right click folders ((Auto-populating) or (Snapshot)) or the root and select Find Items with No Callers.
Fair warning though: there are strings attached. For instance, a parent method might not be used, while an overwrite is. Also, VIs can be used in unused VIs, and these won't be listed until you remove the caller.
The UX of Find Items with No Callers is terrible. The results show (might take some time) and once you click an item it jumps into the project and the dialog disappears... In short, it's quite cumbersome.
If I were in this situation, I'd try anything and everything possible. Even if things are impractical, unreasonable and\or undesirable in the long run. If you try things, you gain knowledge, and you need knowledge to fix this. If you don't you won't find the problem...
Search LabVIEW like a graph!
wiebe@CARYA wrote:
If I were in this situation, I'd try anything and everything possible. Even if things are impractical, unreasonable and\or undesirable in the long run. If you try things, you gain knowledge, and you need knowledge to fix this. If you don't you won't find the problem...
We had a math teacher in engineering college who always said:
If you don't know what to do, then do something!
What he meant was that if you have a math problem and don't know how to solve it, you won't get anywhere by throwing your hands into the air in despair and declare defeat right away.
Try out things, dare to go ashtray and make things even worse. By doing nothing you will never find out what is the problem. By trying out things, even if they are nowhere near to fixing the problem, you may find insights that will eventually help you pinpoint the culprit. Then and only then can you make informed decisions. That might be replacing a certain function that appears to have been getting corrupted, it even might be magically fixed somehow suddenly without a real reason. These are the situations I generally like the least as without knowing what the cause was for the trouble you can't be sure that it won't surface again sooner or later. It could also be that you positively can identify a bug in LabVIEW itself. But just assuming that LabVIEW is at fault is the easy but definitely unproductive solution.
Without a hard proof as to what is the problem, your bug report will simply be put in the pile of "not reproducible" bug reports that are collected but never looked at again. And a large percentage of those bug reports are in fact not worth another look, as they are often the result of PEBKAC (preblem exists between keyboard and chair).
@AdarshaPakala wrote:
- 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!
Surely the team has made detailed commit notes with every commit? This has saved us countless times. I forced everyone to make detailed commit notes with for every VI committed, and the first time we had to go back and see where a bug was introduced and it was easy to find, I no longer had to force them to do it; they enthusiastically took the extra fifteen minutes to give themselves the notes necessary to effectively use the time machine they had created by using SCC in the first place.
You say each commit would have too many notes to do this? You should be committing often. I don't have a "commit schedule". Rather, I commit every time I make a change that I don't want to lose. Small notes for small commits together paint a detailed picture of the state of the software just as small paint strokes define a painting.
@AdarshaPakala wrote:
P.S: As a point is highlighted, I would like to make it clear;
'The last successful build was created 8 months back' that doesn't mean we did not attempt to build it for an 8 months long time. We are facing this build issue from last 3 months, first attempt to build in this release cycle was in the 5th month. We are following 6 months software release cycle(4 months development + 2 months testing) as per our process model, and this was our 16th release and we did not have major issues in the build creation so far. I completely agree with your point and importance of periodic intermediate build, Yes this issue teaches us a good lesson and gives more push for our internal proposal of CI/CD implementation.
That eases our mind.
And it narrows down the problem. Apparently, 3 months ago something changed...
I'd binary search around that approximate date. Try a version, if it compiles, go up 10 (20, 50) commits. If it compiles, repeat. If not, go back 50%. That should narrow things down.
