Jump to content

Closing the node out reference from Get First Matched Node


cmh

Recommended Posts

Hi all,

 

I'm having problems with a program I've written that hangs after some period of running. The program is fairly simple but it does a lot of xml parsing so to fix the problem I'm looking for things like references that are not closed. I have found one unclosed reference in one of my subVI:s but I can't close it without breaking the program so I look to you for help.

 

The reference in question is the "Node Out" reference in the NI_XML.lvlib:Get First Matched Node.vi marked in the attached file CloseRef. What I would like to do is really to wire it to the invoke node (and not use the "Refnum in" there) but that does not work because somehow the reference has changed from a document reference to a node reference. If I just close the "Node Out" reference my program doesn't work (I guess it kills the "Refnum in" reference which I need later on).

 

post-16628-0-03134700-1422206658_thumb.p

 

Any ideas on how I could handle the matter?

Maybe this is not the cause of the program hanging but it's the best candidate I found so far.

 

Thanks

Martin

 

 

Link to comment

Hi all,

 

I'm having problems with a program I've written that hangs after some period of running. The program is fairly simple but it does a lot of xml parsing so to fix the problem I'm looking for things like references that are not closed. I have found one unclosed reference in one of my subVI:s but I can't close it without breaking the program so I look to you for help.

 

The reference in question is the "Node Out" reference in the NI_XML.lvlib:Get First Matched Node.vi marked in the attached file CloseRef. What I would like to do is really to wire it to the invoke node (and not use the "Refnum in" there) but that does not work because somehow the reference has changed from a document reference to a node reference. If I just close the "Node Out" reference my program doesn't work (I guess it kills the "Refnum in" reference which I need later on).

 

attachicon.gifCloseRef.PNG

 

Any ideas on how I could handle the matter?

Maybe this is not the cause of the program hanging but it's the best candidate I found so far.

 

Thanks

Martin

 

It's called inheritance. Node is a more generic object type than Document but a Document is also a Node. Node does not have the same properties that a document has. The node output of the Get First Matched Node.vi is the same refnum as the input, but since the VI uses a more generic Node refnum, LabVIEW silently coerces the Document refnum into a Node. Principially you could Typecast the Node refnum back into a Document refnum, but that is not really necessary here since you have the Document refnum already available in the VI. Also it is not a safe thing to do unless you know specifically that your Node is a document (only really valid for the root node).

 

So what to do here? Close the Document refnum as soon as you don't need it anymore. The Node refnum out from Get First Matched Node.vi is NOT a different refnum but really the coerced Document refnum you pass into the VI.

Link to comment

Hi all,

 

I'm having problems with a program I've written that hangs after some period of running. The program is fairly simple but it does a lot of xml parsing so to fix the problem I'm looking for things like references that are not closed. I have found one unclosed reference in one of my subVI:s but I can't close it without breaking the program so I look to you for help.

 

The reference in question is the "Node Out" reference in the NI_XML.lvlib:Get First Matched Node.vi marked in the attached file CloseRef. What I would like to do is really to wire it to the invoke node (and not use the "Refnum in" there) but that does not work because somehow the reference has changed from a document reference to a node reference. If I just close the "Node Out" reference my program doesn't work (I guess it kills the "Refnum in" reference which I need later on).

 

attachicon.gifCloseRef.PNG

 

Any ideas on how I could handle the matter?

Maybe this is not the cause of the program hanging but it's the best candidate I found so far.

 

Thanks

Martin

 

 

Eyeballing your code, the leak could still exist, but not for the reason initially considered that Rolf explains. Below, demonstration how the dtor conditionally destroys only when no error is input (and an unrelated but additional digression from POLA, returning no error destroying an already-destroyed object).

 

The fix at the app-code layer would be to ensure dtor executes unconditionally (by guaranteeing no error flow in), then merging output errors with upstream.

 

post-17237-0-97852100-1422551730_thumb.p

Link to comment

Eyeballing your code, the leak could still exist, but not for the reason initially considered that Rolf explains. Below, demonstration how the dtor conditionally destroys only when no error is input (and an unrelated but additional digression from POLA, returning no error destroying an already-destroyed object).

 

The fix at the app-code layer would be to ensure dtor executes unconditionally (by guaranteeing no error flow in), then merging output errors with upstream.

 

attachicon.gifScreen Shot 2015-01-29 at 11.10.42 AM.png

 

Ohh, man. Now I know again why I didn't use the DOM Parser. This is insane and goes against all and every LabVIEW convention about destroying refnums. But there are other things in that API that make proper resource handling difficult to do.

  • Like 1
Link to comment

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.

×
×
  • Create New...

Important Information

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