12-17-2009 03:53 PM
Ben and AQ,
With the changes suggested by AQ and some more features in my ExecutionBase class the crashes are still reproducible.
I attach the code for the project with the updated ExecBase class.
/Roger
12-18-2009 03:55 PM
I'm playing with it more. After the workaround I gave you earlier, I'm pretty sure I ran the code without crashing... but I am seeing the crash with the new version you've posted. Did you change anything else between the first version you posted and this later version other than the AlwaysCopy node on the Create VI?
1) It is reasonable to believe that the same bug affects the bottom input of the BundleByName node as well. You're sticking an object inside itself. LV2009 isn't duplicating the object properly. I did this but I'm still seeing the crash. If you've got other instances of this on your other VIs, you'll need to add the AlwaysCopy primitive as a workaround. I searched all your diagrams but didn't see any similar situations, so there may be something else at play here. In related news, I'm not going to be able to get a fix for "doesn't copy" bug into the LV2009 SP1. We're too close to having the service pack finished for me to make further fixes there. The fix will have to wait for LV 2010.
2) Tangent topic: You do not need the To More Generic nodes on your Create diagram. I mention this only because their presence made the diagram hard to read. One of them I can understand if you're passionate about hiding coercion dots, although when upcasting, coercion dots are no-ops -- pure visual feedback to the user with no runtime impact whatsoever. But the other one, the one that is casting the General.lvclass object into LabVIEW Object so you can connect it to the Obtain Queue primitives, is completely unnecessary. Just wire the LabVIEW Object constant directly. All you're setting on that terminal is the type of the queue -- the data on the wire is entirely ignored.
12-18-2009 04:13 PM - edited 12-18-2009 04:19 PM
AQ,
My speculation is that it has something to do with recursion?
If you keep a close eye on the processor load you will see it increase to 100%, even if you set loop rates to more moderate figures than what I have in my example.
My guess is that some LV runtime method will recurse to infinity as I am sticking references of objects inside themselves?
Have a merry christmas!
/Roger
12-21-2009 02:07 PM
12-23-2009 01:08 PM
12-23-2009 07:21 PM
Alright. I figured out a chunk of what's going on.
Bad news: I cannot come up with a workaround for your particular VIs. I know the general problem -- it's that inplaceness bug I told you about before. I found that one by luck, and I have a sense that there's a second one somewhere on one of your VIs but I cannot find it.
Good news: The bug should be fixed in the 2009 SP1. I verified this today. That bug fix release will be available sometime in Q1 2010 (that's the most specific date I know). When I run your VIs there, there is no crash.
It's not what I'm sure you were hoping to hear, but it's the best I can supply at this point.
01-30-2010 04:05 AM
Great news then! Thanks AQ!
/Roger
02-13-2010 08:31 AM
I have re-run my program on the "f3" update, with the same result (crashes). AQ, did you intend the fix to be in LV2010 or in LV2009 SP1?
I've also cleaned up and clarified on how I intend to use the framework
The new code is attached.
BR,
/Roger