LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Editor bug if you drag a case structure over an index/replace elements node on a in place structure

To reproduce:

Drag a case structure over a index/replace array node

UI bug 1.PNG

You'll end up with this train wreck. Autocleanup no longer works

UI bug 2.PNG

Interestingly, you can still get it to compile but setting the boolean to true doesn't run the true case. Warning: dragging the below snippet onto your block diagram will probably crash LabVIEW

UI Bug.png

Select all that and drag it into a new VI. Run autocleanup and the development environment will crash: Exception: Noncontinuable exception (0xC0000025) at EIP=0x00000000

 

Running LabVIEW 2014 SP1 with nothing special.

 

0 Kudos
Message 1 of 15
(4,460 Views)

To quote Obi-Wan

This is not the bug you are looking for..........

 

Now search for "Clear as mud"

 

Having a Wired treminal inside an IPE driving conditional code should break the snot out of that code and cause the compiler to puke all over!  The lack of check for that insanity is causing the crash!  Don't do it!  Just think of how you are abusing the poor IPE.  What if you had a breakpoint on the Inplace Boundary and changed the boolean?  That would necessatate a copy inside an inplace structure....... NO!!!!

 

Or, more to the point as best I understand: (Add duct tape adound head as needed)

 

An IPE must exist in one "Clump"  Terminal Reads exisist in their own "Clump" (although you can read many terminals in one clump)  So you require a clump to read the boolean terminal inside another clump.  Clumps cannot reside in clumps since clumps are clumps that stand apart from each other by definition.  The run arrow should be broken but is not- hence LabVIEW crashes. Makes sence to me  except the clumping algorythm didn't catch the insanity and the run arrow wasn't broken.  so the next edit caused all hell to break loose.

 

(If I missed domething here I am going to learn something today)


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 15
(4,438 Views)

The undesireable behavior occurs regardless of where the boolean control is placed or even if it's omitted. The part about it compiling and the poison snippet was just for entertainment purposes.

0 Kudos
Message 3 of 15
(4,426 Views)

As long as you realize the poison snippete should be busted if the terminal is wired to the con pane....

 

I wonder though.....

 

Back in LV 2012 I reported a similar feature with created Case structures touching the internals of an IPE  Creating a case structure inside an IPE that touched the inner nodes resulted in ghost tunnels. (ones that could not be see except for marching ants after selecting all)  There may be a relationship


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 15
(4,417 Views)

Yes, this seems related. There's definitly some ghost wires/terminals involved. Interestingly, the inner struture type is also unimportant to this behavior. I think it's just trying to put the index/replace in the drawn structure which goes in the IPS which makes it angry.

 

UI Bug2.png

 

Warning: Will crash LV

0 Kudos
Message 5 of 15
(4,404 Views)

Jeff·Þ·Bohrer wrote:

Having a Wired treminal inside an IPE driving conditional code should break the snot out of that code and cause the compiler to puke all over!  The lack of check for that insanity is causing the crash!


No. As pointed out, this isn't the cause here, but even without that, the IPES is not some magic structure which will let you do whatever you want and guarantee that there will be a break or no copies. It is simply an indication to the compiler that you would like *this* operation to be done in place. If possible, it will be done. If not, a copy will be made (for instance, if you branch a wire out of the IPES). In that respect the IPES is not different from any other node on the LV BD. In LV, at least by design, correct functionality always wins over performance and in principle you should *never* get a crash. The only exceptions I can think of is Type Cast, which allows you to manipulate things on your own and buggy compiler optimizations.

 

Oligarcky, if this is a consistent bug, I would suggest adding a link to this thread in the bug thread.


___________________
Try to take over the world!
Message 6 of 15
(4,378 Views)

You know, sometimes I want a special category for closing bug reports that uses the tagline of an old joke:

"Doctor, it hurts when I bend my finger backwards to touch the back of my hand."

"Well, don't do that."

 

There are things in this world untested because of laziness. Therer are things in this world untested because of lack of time. And then there are the things untested because a developer couldn't even imagine, given plenty of time to brainstorm, a user attempting that: the actual definition of "unthinkable." This would, for me, fall into that category. Well, done, Oligarlicky... you have succeeded in thinking "outside the box." 🙂

 

CAR 530250 filed. Low priority.

0 Kudos
Message 7 of 15
(4,346 Views)

> The only exceptions I can think of is Type Cast, which allows you to

> manipulate things on your own and buggy compiler optimizations.

 

And the Call Library Node. Those are the two nodes where you have direct power to manipulate things in ways that LV cannot account for.

0 Kudos
Message 8 of 15
(4,344 Views)

@AristosQueue (NI) wrote:

> The only exceptions I can think of is Type Cast, which allows you to

> manipulate things on your own and buggy compiler optimizations.

 

And the Call Library Node. Those are the two nodes where you have direct power to manipulate things in ways that LV cannot account for.


To be clear, I was referring to native LV code. CLFNs by definition go to external code.


___________________
Try to take over the world!
0 Kudos
Message 9 of 15
(4,328 Views)

 


@AristosQueue (NI) wrote:

You know, sometimes I want a special category for closing bug reports that uses the tagline of an old joke:

"Doctor, it hurts when I bend my finger backwards to touch the back of my hand."

"Well, don't do that."

 

There are things in this world untested because of laziness. Therer are things in this world untested because of lack of time. And then there are the things untested because a developer couldn't even imagine, given plenty of time to brainstorm, a user attempting that: the actual definition of "unthinkable." This would, for me, fall into that category. Well, done, Oligarlicky... you have succeeded in thinking "outside the box." 🙂

 

CAR 530250 filed. Low priority.


Putting a case structure (or some other structure) inside of a IPE structure seems like a pretty routine thing to do. The only thing I did wrong was drawing my structure slightly too big and accidentally bumping into the index array. I definitely wan't trying to break LV when it happened and I don't think I was being all that creative either. And you have to admit, most people will want snippets to be generally safe to drop.

0 Kudos
Message 10 of 15
(4,316 Views)