LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

A bug caused by turning debugging off...

Ok, the attached file demonstrates a problem. The input string driving a "Format into String" node not contain any formatting codes. Consequently when it executes, it returns an error as it should -- unless you turn off debugging. As soon as you do so the error magically disappears. To make it reappear all you have to do is wire an indicator to the formatted string output, and it has to be an indicator, wiring it to the edge of a structure is not good enough.

 

Mike...

 

PS: don't try to figure out why I am doing this. The VI is a much stripped down example to show the problem.


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 1 of 13
(6,533 Views)

Very interesting.

 

Seems like something is too aggressively eliminating code when debugging is off. Note that the old "always copy" inserted into the string fixes things (see picture). 😮

 

alwayscopy.png

 

 

0 Kudos
Message 2 of 13
(6,500 Views)

A lot of (most?) property nodes don't return an error unless the output is wired, but at least that doesn't depend on debugging state.

 

This particular problem must be hard to tackle, since it works fine in development environment, but not in an executable. Unless you enable debugging in the executable to figure out what is happening...

0 Kudos
Message 3 of 13
(6,478 Views)

I see this kind of thing regularly.  Especially on RT when dealing with faulty deploys of inlined code.  Hey, enable debugging and all of a sudden the VI is deployed and stuff works.

 

I've just started treating it as expected behaviour.

0 Kudos
Message 4 of 13
(6,446 Views)

@altenbach wrote:

Very interesting.

 

Seems like something is too aggressively eliminating code when debugging is off. Note that the old "always copy" inserted into the string fixes things (see picture). 😮


It sounds somewhat reasonable, if there's no format string the block is a no-op and it's cut. Interesting.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 5 of 13
(6,437 Views)

@mikeporter wrote:

Ok, the attached file demonstrates a problem. The input string driving a "Format into String" node not contain any formatting codes. Consequently when it executes, it returns an error as it should -- unless you turn off debugging. As soon as you do so the error magically disappears. To make it reappear all you have to do is wire an indicator to the formatted string output, and it has to be an indicator, wiring it to the edge of a structure is not good enough.

 

Mike...

 

PS: don't try to figure out why I am doing this. The VI is a much stripped down example to show the problem.


Sorry Mike but we may want to know what the use case is here to motivate code changes since the magic bullet (always copy) posted by Christian will result in this issue being ignored for a code fix and if anything will be turned into a Documentation CAR adding a footnote about what you found.

 

I have to guess that you are doing something clever and possibly testing strings to see what format they are in...

 

Now the error cluster ( correct me if I am WRONG! You have been at this longer that myself) has not always been available on that node. And tossing any code where the output is not used has been a long standing "feature" of LV.

 

So it seems if anything, the error cluster output should be included in the evaluation when the choice is made to turn code into a NOOP. For code upgraded from the early days, there will be no error cluster so that should not hurt anything. Newer code that has the error cluster but is not wired, same thing.

 

It is only the special case where the error cluster out is used but the string is not that needs some tweaking.

 

So what do you think?

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 13
(6,397 Views)

@Ben wrote:

 So what do you think?

 


Regardless of whether anything will be fixed as a result, I think it would be hard to argue that what happens below is expected or intuitive as a LabVIEW user.

 

Bug.gif

 

This is the behavior whether debugging is on or off.

Matt J | National Instruments | CLA
Message 7 of 13
(6,341 Views)

It's almost the same for some property nodes:

 

No error getting caption.png

Note the control has no caption...

Also note that in this case, wiring to a frame is enough.

Message 8 of 13
(6,322 Views)

@Jacobson-ni wrote:

@Ben wrote:

 So what do you think?

 


Regardless of whether anything will be fixed as a result, I think it would be hard to argue that what happens below is expected or intuitive as a LabVIEW user.

 

Bug.gif

 

This is the behavior whether debugging is on or off.


For the sake of performance, I would side with this being a subtle detail, to be documented under a performance topic or similar.

 

Otherwise we would be forcing LV to include and run code that can be tossed if not for the error cluster. And the idea of a function that is compiled out throwing an error makes my brain hurt.

 

The optimization of throwing away code that produces an output that is not used goes back to LV 6.1 or so. Even back then the FP>>>invoke node>>>Get Image was reduced to a no-op if the output of the invoke node was not used.

 

Wiring the output is enough to allow us a work-around.

 

Just my 2 cents,

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 9 of 13
(6,298 Views)

Yes, parsing the format at run time is probably expensive, but if the error is actually used to make a decision based on the validity of the format string, it cannot be tossed out. I am all for performance, but this primitive can only be eliminated if none of the outputs go anywhere.

Message 10 of 13
(6,283 Views)