Build Specification: Enable Debugging

[mje]

What exactly is the fundamental difference between executable builds when debugging is enabled versus not enabled? Other than the inclusion of symbols and what not so breakpoints can be used etc.

I have an application which I've been building with debugging enabled for months and it has worked beautifully. I've now switched to release mode (not checking the "Enable debugging" box) and spent a few days trying to figure out why the executable no longer functions. I realize I'm being nebulous about this, but I really don't know what isn't working yet, so I can't really go into details. All I know is my executable spins up, shows the splash screen, grabs about 100 MB of memory then...just blocks. I'm making very slow progress mostly due to the long build times (I only run builds when I'm out to lunch, or when I leave for the night, meaning I only get two shots to fix it each day). Any tips on what might be different with respect to debug and release builds?

Last night got me thinking maybe release builds are removing front panels of my dynamically loaded VIs, so that's next on my list of things to check. More news after the (lunch) break I suppose.

I've also noticed the executable goes from 50 MB in debug mode to 24 MB in release mode. That seems like a big difference, but I have no idea what's involved with debug symbols etc, maybe that's normal?

Regards,

-m

[gmart]

Building a "release" executable remove front panels and block diagrams of all dependencies. Block diagrams (but not front panels) are removed of all Startup and Always Included VIs. For a debug executable, all front panels and block diagrams are kept and debugging is enabled for all VIs. There are no concept of "symbols" for LabVIEW built applications so that is not part of a build. So the larger size of your application is due to the inclusion of front panels and block diagrams.

What exactly is the fundamental difference between executable builds when debugging is enabled versus not enabled? Other than the inclusion of symbols and what not so breakpoints can be used etc.

I have an application which I've been building with debugging enabled for months and it has worked beautifully. I've now switched to release mode (not checking the "Enable debugging" box) and spent a few days trying to figure out why the executable no longer functions. I realize I'm being nebulous about this, but I really don't know what isn't working yet, so I can't really go into details. All I know is my executable spins up, shows the splash screen, grabs about 100 MB of memory then...just blocks. I'm making very slow progress mostly due to the long build times (I only run builds when I'm out to lunch, or when I leave for the night, meaning I only get two shots to fix it each day). Any tips on what might be different with respect to debug and release builds?

Last night got me thinking maybe release builds are removing front panels of my dynamically loaded VIs, so that's next on my list of things to check. More news after the (lunch) break I suppose.

I've also noticed the executable goes from 50 MB in debug mode to 24 MB in release mode. That seems like a big difference, but I have no idea what's involved with debug symbols etc, maybe that's normal?

Regards,

-m

[soupy]

I actually just got finished wasting an entire day on this exact issue. In my case it was due to the front panels of the dynamic VIs not being included in the builds. this results in the invoke nodes working on the VI refs to return error 1013 (http://digital.ni.com/public.nsf/allkb/BFDB388E06A4EAA086256FE9007D6174). this will not be obvious if you are not handling these errors....

To fix this issue, do one of the following:

• in the dynamic VI, goto File --> VI properties --> Window Appearance --> Customize... and check "Show front panel when called"
• on the block diagram of the dynamic VI, place a reference to any front panel control (it does not have to be wired up)
• Go into the executable build specification and add the VI as "always included".

[mje]

Thanks for the tips. I had to generate a working executable over lunch, which means I spent the hour generating another debug build, so I can't confirm that all is solved. But this all makes sense, so I'll give it a whirl at the end of day.

I did find out why I wasn't receiving errors. Silly little bug, I had the error out of my run method ultimately wired to the error in of Send Notification.vi, meaning if the VI server call fails my notifier would never signal. So my calling process would just wait indefinitely at that point for the failed child process to spawn.

/facepalm

[mje]

Well that took way too long, but I finally got a functioning release build spec. Iterations are slow when build times are long...

I tracked the problem down to a private VI in a re-use lvlib which is required to have its front panel due to VI server calls made into the VI. The VI is not set to show front panel when called (because it should never be shown), so builds have no way of knowing the panel should be kept. This got me wondering, since the library is used as-is, there doesn't seem to be any way to enforce the panel to be included in a build other than each build specification must manually add the VI (among others) to their always include section. This seems very fragile and strikes me as the wrong way to go about business, especially since the VI is private: the user of the library should have no reason to even have to know about the existence of the VI, let alone be required to add it to each build spec.

I think creating a packed library for distribution might allow the specification, but last I checked (bare LV2010, no SP), creating a packed library out of the lvlib made it nigh unusable as the IDE slowed to a complete crawl, so I've barely even explored that option.

Is there no other way to flag a VI to always hang onto its panel when saved into a build?

-m

[Mellroth]

Is there no other way to flag a VI to always hang onto its panel when saved into a build?

I remove the "Allow user to close window" check mark in Windows Appearance dialog

/J

[Yair]

I prefer creating a property node for any of the controls in the FP. It doesn't matter which property it is and you don't have to do anything with it.

The advantage to doing this is that you can add a comment next to the property node so that this does not break accidentally.

I have also asked relevant people at NI specifically about this and they said this shouldn't break in future versions due to future optimizations, etc.

[mje]

Nice, thanks Yair. I didn't even think to use that to my advantage in this context.