Labview 2013 project using G# crashing when built

[Gimly]

Hello,

I have a very strange issue with one of our Labview project. We have started using Labview 2013 on our relatively big project that uses G# extensively. Everything was working fine up until we tried to compile the project and create an exe from it.

The startup VI works perfectly fine when running through Labview, but as soon as we try to run the compiled .exe, we get a Labview crash with a StackOverflow exception (Stack overflow (0xC00000FD) at EIP=0x3079D546). Of course, since this is a Labview crash, there is no way to refine from where the exception is coming.

I've tried updating Labview and the dependant packages with no luck. I've got in touch with the Labview support team who were helpful but, for now, didn't manage to address the issue. Since our project uses G#, they advised us to post here to see if someone else stumbled upon the same issue.

So, here I am, did someone else had similar issue? Is it a known bug, is there a workaround?

Thanks in advance.

Xavier

[Mattias_Ericsson]

Hi Xavier,

I suppose this really is a LabVIEW issue, since G# is pure LabVIEW. I've seen crashes like this on large LabVIEW projects in general, especially when upgrading the code from an older version.

I would try the following:

1) Open the project to make sure all VIs are in memory. The open one of the main application VIs.

2) Force a complete mass compile of all VIs in memory by CTRL+SHIFT+Run button. This might take a really long time, perhaps more than an hour and will force a recompile of all VI, independen if they needed or not. All VIs will get a "*". When finsihed, save all VIs in memory. This might also take a while, even make LabVIEW in responsive, but do not interrupt. LabVIEW will finish. Please note this is not the same as "Mass compile...".

If above doesn't work:

3) Recreate the project from a fresh empty project.

4) I would try to use Windows 7 64-bit (even if LabVIEW 2013 is 32-bit) with at least 8GB RAM. I've seen build issues when RAM is too small.

Regards,

Mattias

[thols]

I agree with Mattias. You need to go through those steps. LabVIEW sometimes assumes that things don't need to be recompiled, and when they are run without recompile, it will crash.

I would like to add one thing (don't know if you use the project explorer for daily development, but anyway):

As a general rule, especially for larger projects: avoid using the project explorer for daily work, use it only for building distributions. Strange things will happen when using the project explorer in larger projects. You can do almost everything in G# without the project explorer.

Please let us know if it works.

//Thomas

[Gimly]

Hi Mattias, Thomas,

I agree with you, this is for sure a Labview issue, the support team has forwarded my issue to the US branch and I'm waiting for news from their side.

In the meantime, I've tried to force the complete recompile of all VIs with CTRL-SHIFT-Run. It seems to have done something, but the issue is even worse in some way now. The build never finishes, there are no error message or anything, it just stops on "Saving some_vi_name.vi" and shows the "Done" and "Explore" button, but nothing is copied in the target directory. Very frustrating. If I try to re-run the build, it just breaks on "Initializing build" and freezes.

I've tried re-creating the project from scratch on 2013, but it doesn't seem to help, still the same issue.

I guess I'll have to wait for the next service pack.

Thanks for your help.

[griffindore]

Hey Thomas,

That recommendation seems odd to me. I generally recommend the complete opposite. I tell people that when they work on LVOOP, lvlibs, or large developments they should ALWAYS use projects. I also recommend using projects on any and all daily work. I couldn't live without them. Unless you use projects religiously to force seperate application spaces, it's extremely easy to get into cross linking scenarios. Projects will also always show you dependencies and where items are being loaded from disk. You can even open different revisions of your two code bases at the same time in different projects.

If I get to a point where a mass compile is required, I revert to a previous state that is known to be good. Mass compiling large LVOOP projects is painful. Unfortunately like Mattias pointed out, a force mass compile is sometimes required.

Regards,

Mike Lyons

[Mattias_Ericsson]

Hi,

Ok, maybe SP1 will help. I guess LV2013SP1 would soon be out. I would like you to try two more things:

1) Change the destination in your exe-build, perhaps put the classes outside the exe? Any difference?

2) Does a source code distribution work? (do not exclude any vi.lib, user.lib or instr.lib)  If so, try to make a new build exe project based on the source code distribution. Does that work?

I have one large project where I use source code distribution and LabVIEW couldn't build the entire project without crashing (LV2012). Therefore I splitted the build project into two project, one where I put all the main code and all base classes directly linked in the code. Then I created another project only containing the subclasses (that was injected and dynamically loaded) with all needed sub-VIs. In both project I put a post-VI that copied the output VIs to a another directory that would merge the result of the two builds. Some VIs would get overwritten, but since I always build the two project one after another, it doesn't matter.

If a source code distribution works (make sure you include all needed sub-VIs from vi.lib, user.lib, instr.lib), you can make a dummy VI.exe that launches the source code distributed VIs making them run in LabVIEW runtime without the need of development environment.

Perhaps not the most optimal solutions, but it seems that we need to try at least something. Perhaps it will help NI engineers to debug LabVIEW.

Mattias

[Mattias_Ericsson]

Hi Mike,

I think that Thomas point is that LabVIEW projects sometimes can be much slower to work with when having a large amount of classes in memory when you e.g. rename them, clone them etc compared to if you load them in the main application instance directly. I've seen this myself and that is one of the main reasons that we added possibility in the latest G#IDE to be able to clone and rename classes in the main application instance etc. without a project.

However, I do agree with you that projects makes it easier and you get a better overview of the classes in your daily work. I usually creates small temporary projects with just the code I currently work with in the project. This way editing performance of LabVIEW is much better compared if you put all code in a project. Then I use one large build project (or projects) for build and checking linking problems etc.

But I guess everyone have its own way of working. Probably the less frustrating way.

Mattias

[griffindore]

Hi Xavier,

You can test the dummy VI.exe recommendation that Mattias gave without even creating the source code distribution assuming your code is linked properly and all compiled in the LV version of interest. That could speed up your time to see if that works or not.

Several years ago, I was trying to build my G# classes into PPLs. I made some progress with the help of Mattias if I remember correctly. Unfortunately, PPL building wasn't mature enough at that point for my complex LVOOP projects so I stopped. I haven't retried since, but I do know that PPLs have gotten a lot of improvements since the last time I tried. That may also be a viable option similar to what Mattias said. You could get unnecessarily caught up in the complexities of trying to make that option work though.

My concern is that it sounds like you were originally able to build the EXE, but were getting memory runtime errors. It's possible that the cause isn't related to building your G# code via App Builder at all. If you make your EXE debuggable, I think that allows you to hit the LV dev environment instead of runtime engine. I'd be curious to see if you get the same crashes in that scenario. At the very least, you could find out which portion of code is crashing when run in an EXE.

Good luck!

Regards,

Mike Lyons

[griffindore]

Those are some good points Mattias. Clone and renaming classes could certainly have its advantages getting into a different application instance. I've never tested or noticed speed differences in performance of being in main application instance vs project although I would assume the project to have overhead.

For me, I use tons of projects to force getting into different application instances so that I could work on just the items of interest. If using only the main application instance, you could also get slowdowns from all the classes being there when a modification occurs. One other thing that's always bitten me is if I modify a class that's in the inheritance hierachy when the child or dependent classes are not in the same App Instance. It can be pretty brutal getting them all fixed after the fact.

Regards,

Mike Lyons

[Mattias_Ericsson]

Hi again,

Well, I do think you need to make a source code distribution before running the dummyVI.exe. I haven't been able to get this thing to work else. It did work before LV2011(?), but it was the new "separate compile code from source file", that caused problems, especially with vi.lib VIs that is locked and that couldn't be changed. When making a source code distribution, the vi.lib VIs get excutable in the runtime environment.

Do you really have a trick of using a dummyVI.exe with LV >= 2011? including VIs from vi.lib? (separate compiled VIs)?

I really hope I am wrong here!

/Mattias