LabVIEW Crashes corrupts Actor.lvclass datatype

[StevenHowell_XOM]

Good afternoon,

I have had this happen to me a couple of times now and it is a bit worrysome.

While developing my application in the actor framework, I go to open a VI in the project, and I get an error message that LabVIEW has crashed and needs to shut down and wants to take the crash log stack and send it to NI. I cant remember if I was trying to create a new message for Actor or just opening an Actor VI or what, it is intermittent when it happens.

Anyway, after I realunch LabVIEW and go into the project, I have a broken run arrow on everything. I dig into the project and it seems that everytime this has happened, it has somehow corrupted the Actor.lvclass data and has corrupted or removed the Nested Actors Enqueuer array. I go into the Stop Core and the datatype is no longer there on the unbundle cluster wire.

What is causing this, has anyone else seen this behavior?

[AristosQueue (NI)]

Yeesh. No. I haven't seen this. Nor has niACS (pretty sure he would've told me about that).

But, you know what... that sounds more like your project is getting crosslinked against an old version of the AF. You reload and somehow you're pointing at some other version of the AF. The selective delete of that one field is highly suspicious.

As a test, try marking your Actor Framework directory as read-only.

[DMurrayIRL]

I meant to reply to this yesterday- I have seen something similar. I can't remember if a crash caused it, but basically the Actor Framework library was corrupted somehow, with broken run arrows all over. (I also can't remember if I traced it to your Stop Core issue though). Anyway, I fixed it by deleting the AF library on the machine and copying across an identical version from a different machine. This fixed it, and I've had no re-occurances since. 

[wrkcrw00]

I had this same thing happen to me numerous times. The only solution was to delete the AF directory and replace it with a fresh copy from another machine. Since it happened, I've kept a zipped copy on my desktop just in case. The issue was always with Stop Core.vi. I never traced it down, I couldn't find anything and I know I never intentionally changed Stop Core.vi. I did notice that when I created an override vi of Stop Core.vi that the problem occured nearly every time. Even if my override had nothing but call parent method. Once I created the override on all my VI's, I haven't seen the problem since. I would like to know to real problem, to avoid it or fix it in the future.

[Jed394]

I have also seen this before and with dynamic dispatch classes in general.  Sometimes i have fixed it by going into the broken class as you mentioned and opening up every member of the class as well as any classes that override methods.  Its a pain. 

[AristosQueue (NI)]

I'm amazed that none of you have mentioned this before.

So, for those of you who have seen this, see what happens if you mark your files as read-only. We might get lucky and have something throw some sort of "can't write" error.

Are you *sure* it isn't LV crashing and you choosing to recover files or something like that?

[StevenHowell_XOM]

AQ no, I am not choosing to recover, when it crashes, I simply shut LabVIEW down and then when I relaunch it and go into the project the class data is corrupted in actor class. It always corrupts the Nested Actor Enqueuers Array. I was using the MGI Message Maker add on tool, I dont recall if it happened in the message maker that ships with LabVIEW or not. I remove the MGI toolkit and I am trying to see if it happens again.

[wirebirdlabs]

Two places stale linkages hide are 1) the User compiled object cache and 2) class mutation history. Removing both helps flush bugs like this, usually making the bug become a regular compiler error that's easy to identify and fix.

[FabiolaDelaCueva]

You also might want to record a video of this happening. Tools like Jing and SnagIt are great for this. Another option is the steps recorder for Windows 7 or later.

When I was an AE, we used to say that 99% of the problems were solved with something the customer is not telling you, not because they don't want to tell you, they just don't know you need to know.

Sometimes during a video, the person that can solve the problem can spot a mouse click or something else in the way the error is reproduced that the person having the problem did not notice.

[AristosQueue (NI)]

JackDunaway wrote:

Two places stale linkages hide are 1) the User compiled object cache and 2) class mutation history. Removing both helps flush bugs like this, usually making the bug become a regular compiler error that's easy to identify and fix.

Jack, normally I would agree with that as a possibility, but nothing should be causing recompiles or edits to the Actor Framework VIs in vi.lib. That seems very unlikely.

Another thing -- if this ever happens to any of you, zip the corrupt files and send them my way. We can diff those files against an uncorrupted copy. That will tell us whether the original files are somehow being stomped or whether something in the system is preventing them from loading correctly.