Debugging Actors

[AristosQueue (NI)]

Oh... just saw DrJDPowell's posts... he basically said what I just said. 😉

[SJ_Buddy]

Hi AQ,

I would like to work with you in hope you could help fix issue #245148 (— Class Properties dialog sometimes throws timeout error 123 when opening and must be restarted). I can provide code example. But I would not want to post the code for everyone.

May I exchange the code directly with you only?

This issue is killing me right now. I am loosing too much time close/open my projects.

Best Regards,

[AristosQueue (NI)]

Open a service request with an NI application engineer... they have facilities for securely handling customer code and maintaining control over who has access to it.  I don't work on classes officially any more, so I would not be the engineer working on it. And, I have to be honest with you, it probably wouldn't be something that would get short-term attention unless you're swinging a fairly large economic hammer so that the issue gets treated as a high-priority escalation. But opening the SR is the right place to start.

[SteenSchmidt]

AristosQueue wrote:

A way of getting VI references to running clones that didn't make the LV architects wince. You can use Open VI Reference and wire a string to it to open a VI by name. Apparently, no one but me realized that you can give it the name of a clone VI (with the colon+number after the file name) and get a reference to the clone VIs. Turns out, opening multiple references to a clone isn't exactly stable, and really cannot be made stable without redefining what a clone VI even means, so that magic trick may disappear in the future versions of LV.

I use this all the time. In fact it's a common way 'where I come from ;-)' to access clones this way for numerous tasks; debugging, monitoring, even control in some instances.

The Open VI Reference prim even states opening a refnum to a clone as one of the examples in its help text. That particular example statement should probably be removed from LabVIEW if you've found out that it's not stable. Or how about just making the Open VI Reference prim return the 'This VI' ref number only, when the VI is a clone reflection, instead of allowing it in that case to obtain a new refnum?

Regards,

Steen

[AristosQueue (NI)]

SteenSchmidt wrote:

Or how about just making the Open VI Reference prim return the 'This VI' ref number only, when the VI is a clone reflection, instead of allowing it in that case to obtain a new refnum?

I followed up on this idea. It seemed to me to be a really good idea to get the clone ref use case working without much effort.

Turns out there's a problem: passwords. When you open a VI reference, the reference is either authenticated or unauthenticated depending upon whether or not the password for the VI has been supplied. This determines whether or not certain properties/methods fail.

The This VI Reference is ALWAYS authenticated, even if the password has never been entered. That means that if we were to provide an external way to get the This VI Ref then we would be providing a way to pop open any block diagram. So that's a no-go.

[SteenSchmidt]

AristosQueue wrote:

SteenSchmidt wrote:

Or how about just making the Open VI Reference prim return the 'This VI' ref number only, when the VI is a clone reflection, instead of allowing it in that case to obtain a new refnum?

I followed up on this idea. It seemed to me to be a really good idea to get the clone ref use case working without much effort.

Turns out there's a problem: passwords. When you open a VI reference, the reference is either authenticated or unauthenticated depending upon whether or not the password for the VI has been supplied. This determines whether or not certain properties/methods fail.

The This VI Reference is ALWAYS authenticated, even if the password has never been entered. That means that if we were to provide an external way to get the This VI Ref then we would be providing a way to pop open any block diagram. So that's a no-go.

Oh my, that's a major built-in hole in the password protection scheme, you do realize that?

There's nowhere in the LabVIEW help mentioned that This VI refnum defeats the password protection. I have several debugging tools that works by making the user submit the This VI refnum to a global register for the debugger to work with. I specifically ask the user for the This VI refnum to make sure clones don't crash LabVIEW. That was also why I submitted the idea that we should be able to include the This VI object inside an inlined subVI, so that my users could skip that step (but that request was shot down due to reasons that didn't include the very important aspect that being able to do so would make us able to make a subVI that could defeat any VI password protection).

I suggest that the This VI stops being automaticallly athenticated, and then my idea about returning that for clones stands.

Cheers,

Steen

[AristosQueue (NI)]

SteenSchmidt wrote:

Oh my, that's a major built-in hole in the password protection scheme, you do realize that?

I only just learned about that last week while investigating this. According to others, no, this is not a giant hole because the only way to get the authenticated This VI Ref is for the VI itself to hand it out to callers. So you have to have made a conscious choice to hand it out.

SteenSchmidt wrote:

There's nowhere in the LabVIEW help mentioned that This VI refnum defeats the password protection.

I don't know if that's true or not. As I said, I just learned about it. I'll dig into the help and see if I see (or don't see) anything, and file bug report as needed.

SteenSchmidt wrote:

I suggest that the This VI stops being automaticallly athenticated, and then my idea about returning that for clones stands.

Well, that's not going to happen. Too big a break in backward compatibility, and apparently quite valuable for some systems.

[Hooovahh]

AristosQueue wrote:

I only just learned about that last week while investigating this. According to others, no, this is not a giant hole because the only way to get the authenticated This VI Ref is for the VI itself to hand it out to callers. So you have to have made a conscious choice to hand it out.

I don't want to alarm anyone but for the sake of being transparent this isn't quite true.  A VI Ref is simply a U32 (you can use a type cast to confirm) and because of this you can open the VI (but not run) then start guessing VI Refs until you guessed correctly and use that ref to open the block diagram.

Now sure a U32 has 4,294,967,296 possibilities, but in a quick test I could check about 4,5800 possibilities a second so it would take roughly a day to guess each VI Reference number in an attempt to find the one associated with a password protected block diagram.

[AristosQueue (NI)]

Hooovahh wrote:

Now sure a U32 has 4,294,967,296 possibilities, but in a quick test I could check about 4,5800 possibilities a second so it would take roughly a day to guess each VI Reference number in an attempt to find the one associated with a password protected block diagram.

There are far faster ways to circumvent the password on a diagram. I won't describe them here. But a password does NOTHING to secure your IP. The password keeps casual users from modifying VIs, such as folks using your test bench. If you want to breach that wall, it is a wall made of tissue paper. Always has been.  If you want to secure your IP, remove the block diagram when you save.

[Thoric]

---

@AristosQueue (NI) wrote:

I have attached a VI that, given an non-clone VI name, generates the Nth clone name. You can use that to restore the functionality of the debugging tools.

---

Is "Generate Clone Name.vi" still relevant in 2022? I tried this and it gives different names to those LabVIEW gives my clones 

Gah. My bad. I wasn't appreciating how to interpret the call chain properly when using ACBR.