Suspend When Called Bug

[Omar_Mussa]

I found a bug related to Suspend When Called VIs in LabVIEW 2009.

I've posted the details and a video on LAVA here:

http://lavag.org/topic/11252-suspend-when-called-bug-in-2009/

Basically, suspended VI input changes are ignored in suspend mode -- only the inputs that were set by the caller VI are used.  This is different than in previous versions of LabVIEW.

[Vivek_N]

Hello,

This behavior has been reported to R&D under CAR#192207. Thank you.

[Rob_Calhoun]

Has there been any progress on this? Suspend when called is almost unusable with this issue.

It would appear that the problem is due to inappropriate optimization by the compiler during a suspend-when-called.

During normal operation, LabView re-uses the input data's buffers to store output data when it can. This improves performance and memory utilization, because in many cases it avoids calling a release() on one block of memory just to malloc() another chunk exactly the same size. When this occurs the operation (say, add 1 to each element of a 1024 point array) the computation is done in-place on the input array and the pointer passed to the output array. This violates dataflow but no one is looking 🙂 so it is ok. Next call, the bogus data in the buffers are wiped out by the caller's data. All is well.

But this optimization is inappropriate when suspend-when-called. Here the inputs and outputs MUST be kept in different buffers (different even from the caller's) so that the user can look at and possibly change them; also the user is allowed to run the VI as many times as desired. Sharing buffers leads to data corruption. 

The attached example shows the problem.  The subVI is designed make the optimizer extremely happy: it has the same data types at output as input, and the array doesn't change size. "Show buffer allocations" shows that compiler thinks it can re-use all the buffers. Run "RunMe.vi"; when the subVI suspends, keep hitting the run arrow: each time the VI is run, the values of the input array gets bigger and bigger!

There is a partial workaround, which is to place a "Always Copy" compiler hint (the "*" node) on the input wire; this will prevent the output-to-input corruption.  You still cannot edit the input control on affected VIs.

(On the feature request side, it would be great if Suspend When Called would have some kind of indication as to whether it has been run or not. When you have half a dozen suspends on, it is hard to remember whether you have run it or not.)

-Rob 

[Vivek_N]

Hello Rob,

There is no fix currently available for this issue.  If you would like to submit a feature request, please do so at the Product Suggestion Center: http://digital.ni.com/applications/psc.nsf/default?openform . We really appreciate the feedback as we review this when making decisions on our products in the future. 

[BruceMoyer]

I'm having strange issues with Suspend When Called in LabVIEW 2009 SP1.  When I have a VI suspended and it creates an error after running it, if I run the VI again (without returning to caller), the error magically appears on the input and causes the code not to execute because of the input error that that shouldn't be there.  The input error is not seen until after I click the run button, so it is too late to change the input value.

I'm having a hard time debugging without Suspend When Called.

Bruce

[Vivek_N]

Hello Bruce,

This has been noted as CAR #196654 and we, unfortunately, do not have a fix for this yet. I do apologize for the inconvenience. As a workaround, you could possibly use breakpoints in the subVI and then step into it when needed. 

[Jon_S.]

CAR 196654 was actually a duplicate of CAR 192207.  This bug has been fixed for LabVIEW 2010.  You can search the LabVIEW 2010 Readme for more bug fixes.

[BruceMoyer]

Thanks, I verified that Suspend when Called does work correctly (using a simple test example) in LV2010.  I guess that means there's never going to be a fix for the previous version (2009). 

Thanks,

Bruce