BUG: Creation process for orphaned linked output tunnel causing "LabVIEW Save error code 5: BD Heap" error

[TeaEarlGreyHot]

I encountered a "save error code 5: BD Heap" problem.  After finding an older thread about the BD Heap error, I was able to fix my problem and determine steps to reliably create unsavable VIs.  I'm not sure of the status of CAR 222390, referenced in the old thread, but this test case should be added.  The frames in the sequence structure below illustrate a process to create an orphaned linked output.  

 This sequence causes both LabVIEW 2015SP1 and LabVIEW 2017 32bit to error. 

[billko]

I guess it's because you have a broken wire in the other case?  (If i clean up that wire, everything seems to be okay.)  I guess it's a bug because nothings says you can't save a broken VI.

[TeaEarlGreyHot]

There is no broken wire in the other case.  There are no errors with the VI.  The other case was modified in the same manner as the visible case.  I'd attach a VI snippet, but it does not exhibit the problem after import; the linked tunnel indicator on the output disappears after import.

Full sequence:

1. Starting with a case structure and linked input/output tunnels, delete the wire into the input tunnel (outside the case structure), leave the broken wire and input tunnel

2. Wire through the case structure, creating a new tunnel, and connecting to the broken wire inside the case structure. At this time, the input will become an output and the linked triangle indicator will disappear.  The linked output will retain the white triangle.

3. Delete the original input tunnel

4. Connect inside of new tunnel to broken wire in other cases, deleting spurious branches as needed.

[wiebe@CARYA]

---

@TeaEarlGreyHot wrote:

Full sequence:

1. Starting with a case structure and linked input/output tunnels, delete the wire into the input tunnel (outside the case structure), leave the broken wire and input tunnel

2. Wire through the case structure, creating a new tunnel, and connecting to the broken wire inside the case structure. At this time, the input will become an output and the linked triangle indicator will disappear.  The linked output will retain the white triangle.

3. Delete the original input tunnel

4. Connect inside of new tunnel to broken wire in other cases, deleting spurious branches as needed.

---

This information helps a bit, but I still can't reproduce it. Maybe because I'm trying in 2013, but probably because it might depend on the exact order of thinks you do. Maybe a video will help (it's probably a lot of work)?

Can you post the VI you can't save?

[TeaEarlGreyHot]

I hadn't tried 2013 yesterday but confirmed that it is present there as well.  The attached VI was back-saved from 2017 but I created the same thing easily in 2013.  To trigger the bug, delete the bottom error tunnel in the case structure. Deleting the tunnel doesn't leave any broken wires in my testing, but if it does, a block diagram cleanup is fine.

[BowenM]

I can replicate in 16.0f2

[wiebe@CARYA]

Works fine for me. I can delete the bottom tunnel, and can run the VI without any problem. But never mind, I don't mind not being able to reproduce a bug.

[BowenM]

---

wiebe@CARYA wrote:

Works fine for me. I can delete the bottom tunnel, and can run the VI without any problem. But never mind, I don't mind not being able to reproduce a bug.

---

But can you save the VI after you delete the bottom tunnel?

[wiebe@CARYA]

---

@BowenM wrote:

---

wiebe@CARYA wrote:

Works fine for me. I can delete the bottom tunnel, and can run the VI without any problem. But never mind, I don't mind not being able to reproduce a bug.

---

But can you save the VI after you delete the bottom tunnel?

---

Ah, sorry about that. No I can't.

At least it's easy to fix, as long as you haven't been working 2 hours on a huge VI and then get this error.

I miss the days where these kind of errors reported the UID of the corrupt object.

[TeaEarlGreyHot]

In case the instructions weren't clear, here's a video of the steps, taken from LabVIEW 2017 32bit, the same steps work it in all the versions I have available for testing: 2009, 2013SP1, and 2015SP1.

This is obviously a minimal test case VI with no practicable use.  In my original case, the changes were much larger and there was no clear indication of the cause.  Without lucking upon the five year old thread, it would have been substantial rewriting.