Error FPProtocol.cpp line 4405 using remote panel and subpanel

[LLindenbauer]

Dear all!

I have recently experienced repeated crashes of the LabVIEW IDE when manipulating a subpanel while remote debugging (LabVIEW 2016, Win10 accessing Win7) giving the above mentioned error message.

Automatic diagnosis forwards me to these two links:

https://sine.ni.com/srm/app/community_td-p_240472

https://sine.ni.com/srm/app/community_td-p_240471

However, they seem to be be legacy links now leading to the generic support landing page. Can anyone access them?

There are also two threads from 2005 reporting an Error in FPProtocol.cpp (https://forums.ni.com/t5/LabVIEW/Error-FPProtocol-cpp-line-3244-using-remote-panel-and-subpanel/m-p/...), altough I don't quite unterstand what they were talking about when they solved the issue by  "casing out the property node". What would that mean in 2021-terms?

Sadly, I cannot post the full VIs on this, nor do I currently have steps for consistently reproducing the crash. I do not know if that would be possible at all, given that it may very well be dependent on specifics on both systems.

The debug log contains multiple <DEBUG_OUTPUT> tags:

DWarn 0x5C359BD0: no freeRange list or no elements
e:\builds\penguin\labview\branches\2016\dev\source\vi\cloneVI.cpp(412) : DWarn 0x5C359BD0: no freeRange list or no elements
minidump id: 9f899c00-7706-4eec-bf19-2a16017e0e78
$Id: //labview/branches/2016/dev/source/vi/cloneVI.cpp#6 $

DWarn 0x5C359BD0: no freeRange list or no elements
e:\builds\penguin\labview\branches\2016\dev\source\vi\cloneVI.cpp(412) : DWarn 0x5C359BD0: no freeRange list or no elements
minidump id: a039c423-cc73-4ecb-867b-d10b9b744c70
$Id: //labview/branches/2016/dev/source/vi/cloneVI.cpp#6 $

DAbort 0x06CA5C73: Frontpanel Deadlocked
e:\builds\penguin\labview\branches\2016\dev\source\server\FPProtocol.cpp(4405) : DAbort 0x06CA5C73: Frontpanel Deadlocked
minidump id: 0a19625f-9401-4bd0-a6df-817707a918d6
$Id: //labview/branches/2016/dev/source/server/FPProtocol.cpp#8 $

Sadly, there are no penguins around.

[wiebe@CARYA]

It's probably not just the subpanels, but the combination of clones and subpanels.

I did have a lot of crashes in the past with clones being closed while being in a subpanel, recursively. So a clone with a subpanel containing a clone.

Do you use any callback events?

They made this much worse.

Remote debugging might simply slowdown some parts, causing a race condition to trigger the crash.

I resolved the clone\subpanel problem by making each clone insert and remove itself. I usually end up replacing the callbacks with dynamic VIs. When started properly, they die when the creator dies, just like callback VIs. 

[LLindenbauer]

---

wiebe@CARYA wrote:

It's probably not just the subpanels, but the combination of clones and subpanels.

I did have a lot of crashes in the past with clones being closed while being in a subpanel, recursively. So a clone with a subpanel containing a clone.

Do you use any callback events?

They made this much worse.

Remote debugging might simply slowdown some parts, causing a race condition to trigger the crash.

I resolved the clone\subpanel problem by making each clone insert and remove itself. I usually end up replacing the callbacks with dynamic VIs. When started properly, they die when the creator dies, just like callback VIs. 

---

Thanks! I would say Yes to all of that. Looking back the program started acting up since I introduced a callback VI for a .NET event. The event itself was not triggered before the crash.

I don't see how I could replace a .NET callback with dynamic VIs, but moving the respective code to an Assembly proper may work.

I don't know when I'll get around to trying able to report success, but for now, the callback seems to be a strong indicator.

Regards,

LL

[wiebe@CARYA]

---

@LLindenbauer wrote:

---

wiebe@CARYA wrote:

It's probably not just the subpanels, but the combination of clones and subpanels.

I did have a lot of crashes in the past with clones being closed while being in a subpanel, recursively. So a clone with a subpanel containing a clone.

Do you use any callback events?

They made this much worse.

Remote debugging might simply slowdown some parts, causing a race condition to trigger the crash.

I resolved the clone\subpanel problem by making each clone insert and remove itself. I usually end up replacing the callbacks with dynamic VIs. When started properly, they die when the creator dies, just like callback VIs. 

---

Thanks! I would say Yes to all of that. Looking back the program started acting up since I introduced a callback VI for a .NET event. The event itself was not triggered before the crash.

I don't see how I could replace a .NET callback with dynamic VIs, but moving the respective code to an Assembly proper may work.

---

For .NET and AX callbacks, there's no replacements.

You can unregister those events. Doing the unregistering, remove from subpanel, closing the clones in the right order, recursively, might help. If you can figure out the right order of course.