Jump to content

Reentrancy bug in Write Key (Variant) VI?


Recommended Posts

I've been playing around with the variant configuration palette this week, and I think I found a bug in the Write Key (Variant) VI. The VI will insert escape characters into the section and key name strings to conform with INI file syntax. I've noticed, though, that if I use a file path as the name of a section that holds a cluster, it inserts multiple escape characters at each point, instead of just one. The image below explains it (hopefully).

writekeybug.png

It looks like this bug only shows up when two conditions are met:

1. The section name contains escaped characters, like ‘\’. My section names are file paths to .lvclass files.

2. The variant key contains a cluster or an array of unknown type, causing the VI to be called reentrantly.

Since the VI has to be called reentrantly, I haven't thought of a workaround yet. (Well, I guess I could restructure my file to stop putting paths into the section name, but I'd rather not have to.)

I can think of two approaches to fix it, though. One is to add logic that counts the recursion in the VI and ensures that only the first instance executes the Encode subVI. Another is to encapsulate the multiply executing logic into a reentrant subVI, leaving out things like the Encode subVI so they're only called once from the main Write Key (Variant) VI.

Link to post
Share on other sites

Yes, I'd noticed that too. A fairly easy way to fix it would be to pass the unencoded strings into the recursive calls, rather than the encoded ones.

It does seem a little unusual that this VI was written to be called recursively - I would have thought that creating a queue of keys would be a simpler way to go, though perhaps a little more overhead in the case of only having a single key.

Link to post
Share on other sites

I've been playing with this a bit and I am able to duplicate your issue. A cluster of clusters as the "key-value" increases the number of extra slashes added to the Section name.

However the "Read Key (Variant).vi" still handles reading all the extra slashes correctly.

Can you give us a use case where the extra slashes are causing an issue?

Do you have a need to read the config file with something other than the "Read Key (Variant).vi"?

Link to post
Share on other sites

I'm trying to write an abstract class for serializable (to disk) objects, and I'd hoped to use the open-g VIs to do it. One design constraint is that I want to be able to write an object description by hand or from another application/language, given prior knowledge of the object (from a design document, etc.). If the number of escape characters in the section name varies, that becomes a lot harder to do.

Link to post
Share on other sites

I'm trying to write an abstract class for serializable (to disk) objects, and I'd hoped to use the open-g VIs to do it. One design constraint is that I want to be able to write an object description by hand or from another application/language, given prior knowledge of the object (from a design document, etc.). If the number of escape characters in the section name varies, that becomes a lot harder to do.

Just to make sure I understand, you are looking to be able to write the INI file by hand that will define the cluster?

Link to post
Share on other sites

I think so, yes. I haven't seen another general-use serialization class floating around NI or LAVA, so I thought I'd make my own. This is mainly a thought exercise. If it pans out well, I'll probably try to use this base class in some side projects to see how I like it.

Link to post
Share on other sites

I would definitely call this a bug. How I typically deal with such things is to create an argument called "in recursive call?" and warn the user to leave it unwired, but wire up a TRUE whenever calling it recursively. If this input needs to be hidden (which is probably a good idea), then the actual recursive VI can be moved into a private subVI with the public VI being a thin wrapper around the private, recursive subVI that only passes through all the inputs/outputs (except for the private "in recursive call?" input).

post-17-0-60145700-1315675702_thumb.png

Link to post
Share on other sites

I'm not sure but what is call stack of a recursive VI? Wouldn't that show the same VI name (except for the instance number)?

So we can autodetect it's in a recursive call.

Ton

I think that "call stack" means the "call chain" -- if the caller's name is the same as the current VI's name, then it's recursion.

I threw a small VI together that does this:

Recursive Call.vi

post-17-0-60693800-1315716650_thumb.png

Perhaps this could be a useful OpenG VI. Note that it should probably be improved to test for A >> B >> [C >> [..]] A recursion (by checking for the callers name in any location in the call chain), rather than just A >> A recursion (by only comparing the caller with the caller's caller).

My guess is that passing in a parameter indicating that it's a recursive call is probably a bit faster than programmatically inspecting the call chain.

Link to post
Share on other sites

For some reason, I'm no longer getting emails about replies to this thread. Not sure sure why, it shows I'm monitoring it.

I like the "in recursive call?" terminal option, but in the case of using a path for a section name (or anything that already has a '\' in it) the section name will still end up with double slashes in the config file. Though this is probably needed due to the '\' being the ini file escape character. But at least it would be predictable.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Jim Kring
      [Update: NI Bug 974336]
      There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here).
      Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet.
      Coerce to Variant Fail (LV2019).vi


       
      Note that adding another element to the outer cluster causes the problem to go away.


    • By Bas de Jong
      Hello, I'm trying to display an animated GIF on the front panel. This gif should be loaded programmatically based on some user event. My google search led me to use the OpenG Read GIF File (Animated)__ogtk.vi file. However, loading a GIF is extremely slow. It takes almost 20 seconds to execute the vi when I load the attached GIF (I found randomly on the internet). Is this normal? And if so, is there a way to load a gif faster? Because I need to load several and I cannot afford to load maybe 2 minutes only for the gifs.

    • By ShaunR
      Maybe others have seen this but I only became aware of it recently so I apologise if there is already a CAR for it.
      The following demonstrates a difference in behaviour between LabVIEW 2017 and previous versions (back as far as 2009, maybe further).
      The VI registers an event when it starts (in the timeout case) and generates a user event when the Increment button is pressed.
      The expected behaviour is that the counter will increment by one every time the button is pressed. This is the case for LabVIEW versions prior to 2017. In 2017, the user event is never fired, nor is there an error emitted by the generate user event.
      To get the VI to operate as expected in 2017; change the event refnum tunnel to a shift register. This seems to indicate that the refnum prototype is stomping on the dynamically allocated reference whereas in previous LabVIEW versions it would not. Note also, that when using the shift register, the cases do not need to be "wired through" as would be expected with similar functionality in a normal case statement.
      evnt.vi
    • By A Scottish moose
      Hey everyone,
       
      I am working on a backup function for a test executive.  The backup uses the 'class to XML' vi to create an XML string and then save it to a file to be reloaded later. All of my test specific information lives in the class (or one of it's children).  I like this functionality because it makes backup and reload brainless.  It just works.... until now... I've got a test class for my current tester that's grown rather large.  Everything works fine, until the tester loads some waveform data into either of the waveform arrays.  Without data in this field the class reloads just fine, otherwise if fails and says the XML is corrupted.
       
      As you can see in my backup vi I have built in a work around that flattens the waveform arrays to strings, drops them back into the class private data, deletes the waveform arrays and then writes the class.  This works! Much to my surprise both waveform data and the rest of the class data are written to file and reloaded without error.  
       
      Does anyone have any knowledge or experience with this? 
       
      Cheers,
       
      Tim


    • By fennectp
      Hi all,
       
      I've got a customer that wants to zip/unzip files on their cRIO-9035, so I had them playing with the OpenG Zip tools to see if it would fit their needs. Although they've found that they can zip files on their cRIO just fine, they find that they get disconnected from their RT target and the shell shows the following error message:
      LabVIEW caught a fatal signal 15.0 - Recieved SIGSEGV Reason: address not mapped to object Attempt to reference address: 0x0x10000000 stdin: is not a tty  
      The zip file they're testing with includes two simple .txt files with short strings in them ("booya" and "booya2"). This file unzips just fine on the host PC with the "ZLIB Extract All Files To Dir" VI, but when copied over to the cRIO and unzipped via the same VI, it only unzips the first text file and the resulting file doesn't have any text in it.
      I've attached a copy of the project and the zip file I used to reproduce this behavior using a cRIO-9033 that I had on hand. (The only thing I can't provide is the cRIO >_<)
      Could anybody tell me what I'm doing wrong? Any suggestions as to what other workarounds I could take to zip/unzip files on a LinuxRT target would also be very much appreciated!
       
      Regards,

      Tamon
      Unzip on cRIO-9033.zip
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.