Weird behaviour with inlined SubVI's

Question

Every now and then I've ran into some serious weird behaviour where I've eventually traced it down to some inlined subVI. It has seemed as if the values used inside the inlined subVI don't match what the calling VI is feeding into its inputs. I haven't been able to consistently reproduce this issue so I apologize for the vague description, but since I felt I should finally address this and I couldn't really find anything similar by searching, I'll do my best to describe it and we'll see what turns up.
As I mentioned, the issue certainly doesn't occur consistently. I use inlined subVI here and there and most of the time there are no problems whatsoever. I ran into the issues randomly I think four times now, first three of them were on LV2013 and this last time on LV2014. In all cases I have been using AF and I think the first times were actually with an actor class. At the time I thought it might have been related to the AF, and it still might, but now the last time it wasn't the actor class itself but a data member of one. So far all of the problems have occured with class methods, and I think the "corrupt values" have been the object private data, but I can't confirm this.
This time the inlined subVI was a static dispatch method with contents shown below on the left and the calling on the right.
I'm showing the calling just to point out that when I was investigating the problem and I probed the object wires before and after the inlined subVI the values (Calibration.X Step and Calibration.Y Step) were OK, but the result of the VI (Point out) was some insane value as if the actual division inside was performed by corrupt data. I think that the output value wasn't Inf, though, so the divider might not have been a default value such as 0.
Other notes:
I checked that the wires are connected to the inputs and outputs
As I mentioned, the projects have always been relatively large AF setups, the problematic method has been an actor method or a method called by an actor somewhere down the chain. I have no reason to assume AF is the culprit, I'm just pointing this out, just in case
The problem seems to occur quite randomly but once it "starts" it doesn't go away until I find which inlined subVI it was and change it to a normal VI call
The problem might not even be specifically inlined subVI related but for example pre-allocated VI related instead
I don't know whether the problem would occur in a built executable as well, so far I've only ran into them while testing while developing and fixed them there
Looking at the "Known Issues" related to inlined subVI's I don't know if this related to them. The other one deals with execution systems, which I haven't touched to my knowledge, and the other one says "An Inline public methodVI calling a private-scope method VI, inlined into a non-class caller may give a runtime error when trying to call the private method from the inlined code in the non-class caller."
LabVIEW version is 14.0.1 (2014 SP1 32bit) on Windows 8.1
Yep, reading through this post I gotta say I'm not expecting much, what a mess, but it would be great to find out if anyone else has ever ran into similar problems or has a clue what's going here.

Answer 1

Just for the sake of your sanity, I've seen "funky" behaviour with inlined VIs also, but on Real-Time targets.
I've never been able to narrow down the exact problem but it seems to be related to changed made to inlined VIs not being reflected in the compiled code od VIs which call them.
I've reported it but without code which can actually reproduce it, it cannot be fixed.
Say hello to my little friend.
RFC 2323 FHE-Compliant