Actor Framework Discussions
AF PPL Crashes LabVIEW 2021 SP1 when Searching
It's not really the build spec that's different, but the AF library itself. We modify it (mostly) as per Stefan's instructions here:
And actually, I did some more testing and while removing Reply Msg fixes the issue for very minimal projects, it didn't fix the crashing issue in our larger ones. I even went ahead and removed ALL additional Msg.lvclass files called out in the above instructions with no luck. I'm thinking maybe it's the inclusion of AFDebug (which we're using for some tools which is why we explicitly include it) that's causing the problems now...
I thought I had a counterexample, based on my memory of initially testing this when Casey told me about it, but I think I must have used a real project that contained the Reply Msg library I have.
Consequently, my testing is now as follows:
- Adding my Actor Framework.lvlibp (either to the project directly, or via Dependencies) on Windows (My Computer target) doesn't produce a crash when the VI is very simple and there are no other VIs in the library.
- This library does not include Reply Msg (or Batch, TDSM, Report Error, SAM)
- This library also does not include AF_Debug (all the VIs from that library are just removed)
- Adding my "AF_Messages-PPL.lvlibp" (with all of the previously mentioned messages) does produce a crash when searching for the Add button (default option for Ctrl-F).
- This library contains Reply Msg
- This library does not include AF_Debug
- This library depends on the first (Actor Framework.lvlibp)
- Both libraries are built using 2019 sources with the tickbox to enable loading in future versions
- Debugging was enabled (as in, debugging for the PPLs - not removing BDs, etc)
- The tested version was 21.0 (32-bit) LabVIEW
So I think AF_Debug isn't a requirement to cause a crash, but Reply Msg might be.
Darren, if you want to see the source I'm building this from, you can PM me a GitHub username (yours or whoever wants to look into it) and I can add read access to the repository with the code, or alternatively I can zip up the contents and email/filesender/whatever them to you.
The PPLs are attached for reference, in case it helps.
@CaseyM wrote:
Can you tell us exactly how it's corrupted? Do.vi within that class seems to open fine within LabVIEW so that would imply to me that the corruption is more hidden.
LV R&D said the corruption occurred as part of the PPL build and had to do with the Error Ring XNode in Reply Msg.lvclass:Do.vi. Can you manually edit your Do.vi and replace that Error Ring with the equivalent call to Error Cluster from Error Code.vi and see if that fixes the crash?
P.S. - I've already verified that this is the only XNode currently in the AF codebase.
I was able to do some more testing today and here are my notes:
- Replacing the Error Ring with the Error Cluster from Error Code seems to fix the issue, however...
- We make use of the error ring in other PPLs that are built on top of the AF PPL. If the Error Ring is the culprit, is there a way to search and replace this node since searching is what causes the crash in the first place?
- The above would explain why I don't see a crash in a very simple project, but I do in our larger project with multiple PPLs.
- I don't see any difference regardless of the bitness and version of LabVIEW in which the PPL was built.
At this point I'm fairly convinced that the Error Ring XNode is indeed the cause of the issue. Do you have a guess as to when this could be patched? Or suggestions about how to find and replace any other Error Rings in our own PPLs in the meantime?
We went through our PPL library and it looks like it's not just the Error Rings that cause the crash but any node that uses an XNode (e.g. Match Regular Expression). We've removed/replaced them as a stopgap measure and the crashing seems to have gone away for now.
