Malleables within Malleables = LV Crash?

[CoastalMaineBird]

LV 2018 SP1

I have a problem which seems to be related to having a Malleable VI within another malleable VI.

This is a COMPILER crash, not a run time crash. 

I'm building a PPL if that matters.

This code compiles fine.  MAKE NAME is a malleable which accepts an ENUM (which it converts to a string) or a STRING.

When I use the above code in a VI, it also compiles OK:

The MAKE FULL PROPT NAME vi contains the same code:

Note that if I change that to a VIM (which is what I want) instead of a VI, then I get a crash at compile time:

 

This is reliable - I can switch back and forth between VI and VIM.  VI never crashes, VIM always does.

Is there some rule about VIMs within VIMs that I missed?

In this case the MAKE NAME VIM is simple enough that I can duplicate it where I want it, but I don't know why it's happening.

Ideas?

[billko]

I don't think malleable VIs and packed libraries play well together.

[CoastalMaineBird]

Well, I've run into the fact that a VIM compiled into a PPL cannot "malleate" (is that a word?) any more.

I understand that - it's a compile time phenomenon where the compiler chooses how to compile based on input datatypes, and it cannot change the code if it's inside an existing PPL.

But that's not the case here - all the VIs in question are free-standing (not in PPLs).  It's just that the end product will go into a PPL.  Since VIMs are inline, there's a copy made for each instance, so I don't see a reason why it won't work.

In any case, crashing is not a reasonable response.

[CoastalMaineBird]

For the record, I am able to have a VIM inside a VIM inside a VIM in a completely new project.

The same code I want to work here, will at least compile without a crash if it's in a new project.

So I have some conflict somewhere.

[billko]

Interesting.  Sorry i wasn't any help.

[CoastalMaineBird]

So, a day and half of watching LabVIEW crash over 50 times has led to this discovery.

The "Test Facts" terminal in the above pictures is a TypeDef.  It contains mostly standard things ( strings, time stamps, integers. and one custom STRICT TypeDef enum called "Unit #".

"Test Facts" was set to be strict, because that's my default construction - I set them to be non-strict ONLY if I need them to be non-strict (usually because I need to manipulate properties of cluster members).

If I set "Test Facts" to be NON-STRICT, I can compile it OK (I presume it will run OK, too).

If I set it back to STRICT, it will crash. Every time, upon compile.

I can go back and forth, and it's reliable.

I have a hunch this is related to the weird behavior of PPLs: If I include a TypeDef Enum as a terminal in a VI that gets put into an ENUM, then it becomes a DIFFERENT type, as measured by the coercion dot.  A constant created from that terminal will have the same type and path, but it is coerced, because it is different from the typedef that I started with.  That's been true for years.

Now (I am new at malleability) my guess is that the compiler is trying to "malleate" that cluster and cannot do it for some reason.

If I change it to NON-STRICT, it works  (I see a coercion dot at the VIM's terminal for it).

If I move that cluster outside the VIM and do the unbundling there, then it works.

[Kyle97330]

If you can create some code that will always crash LabVIEW and can make a simple enough bit of test code that always makes it happen, I recommend opening a support ticket with NI (assuming you have a current SSSP) to log the issue.  They probably can't help you fix it other than to suggest workarounds, but it'll get a CAR filed and possibly by LabVIEW 2022 or 2023 they might fix the bug.