Bug editing inline vi that has "separate compiled code" checked

[nanocyte]

I'm seeing this issue on an ARM Linux RT Target. Here's how to reproduce:

• Drop an inlined VI into a "top level VI".
• Run the top level VI
• Edit the inlined VI — Optional: you can change connector data types and save.
• Run the top level VI — you won't be prompted to resave and deploy the edited VI, the top level will just run. The inlined VI will execute as if you did not make the edit. If you did the optional step above, the top level is expecting the new datatype and you might get this error:

LabVIEW caught fatal signal
17.0 - Received SIGSEGV
Reason: address not mapped to object
Attempt to reference address: 0x0x58d9b600

[eltico]

Hi nanocyte,

Thanks for letting us know about this. I've tried it with a cRIO-9064 and LabVIEW 2017 and it seems I don't see the same results.

If you are using this same version, please, be more specific with the procedure to reproduce this. If you are using a previous version of LabVIEW, it seems that it has been already fixed but I am not sure on which version.

Please, tell me more about your system.

Regards,

PedroR

[nanocyte]

I'm using 2017. Are you sure you've both inlined and separated compiled code? You're getting a normal save prompt at step 4? I'm not sure how to be more specific. I've seen it on several computers, with several different code sets, and a couple different targets. I'm not sure why you aren't seeing it. I guess I could call in for support but I assumed it was a common issue.

[eltico]

I am getting a normal save prompt, it says that the top level VI has unsaved changes and when I click on "List unsaved change..." it appears that the VI was recompiled and subVI call modified. 

With the code I am using it also seems that it respects the changes I made on the Inlined VI. I am not sure though, what do you mean with separated compiled code?

Feel free to call support, that might allow a more fluent communication.

Regards,

PedroR

[nanocyte]

Ahh, that's probably why you're not seeing the issue. Here's the document that describes how and why to separate compiled code. Make sure both the top level and the subVI have compiled code separated.

And, just so we have concrete examples, here's my inlined code

And here's the top level

Changing the constant "5" in the inlined code to say, "6" works fine when executing under the local computer—the top level will output 6.xxx. but if you do the same thing with RT, the top level outputs 5.xxxx

[eltico]

Thanks for clarifying that. I looked at this and I found a way to bypass it. From what I read on the information you sent, it seems that the code for each VI is compiled apart, I understand that this is not compiled again when you save but when you either run it or force recompile it.

I tried running the inlined code after saving it but that didn't work so I tried force recompiling the entire hierarchy (check the link below) and it worked. 

http://digital.ni.com/public.nsf/allkb/C1C6FE6231966E278625661F0054A970?OpenDocument

I hope this helps.

Regards,

PedroR

[nanocyte]

I'm having some trouble reproducing what you're seeing. When you say so I tried force recompiling the entire hierarchy you mean you went to the white run arrow on the top level VI and held down the control and shift key and then clicked the arrow? That's not working for me. The top level just keeps running the original subVI. Also, the original issue where you change code but it doesn't get changed in the compiled code is potentially dangerous. I can see an issue where some developer makes a change introducing a bug and doesn't realize. Also, it can cause a crash like the one I logged above. I think especially considering it's on RT systems where users are expecting high reliability, it makes sense to generate a CAR for this.

[DahlmanR]

I do not have the system available to me to try and reproduce, but in order to put resources to narrowing down what may be happening, it might be easier for you to work with an Applications Engineer to get consistently reproducible steps, and the AE can, if necessary, reach out to R&D or file a CAR. 

You can report a bug and work with National Instruments by selecting "Report a bug" on the following page: 

 https://sine.ni.com/srm/app/getassistance 

[eltico]

I am not sure why it doesn't work for you. Did you make sure to save the subVI first?

If it doesn't work, please, follow DahlmanR's advice.

Regards,

PedroR