Do close primitives that return errors cause memory leaks?

[GeorgeG]

The close/release primitives for things like files, queues, notifiers, VISA references, TCP sessions, Application/VI/Control refnums, etc have an error out terminal. Many return error 1 if the input refnum is invalid (like a constant) or has already been closed. Close reference for VI server seems to return 1026 under the same conditions.

What other conditions could cause a close function to fail besides having an invalid or previously closed input reference?

Assuming there are other conditions, if a close function does fail, does it create a memory or resource leak?

If by chance there are different answers, I am working in three contexts: IDE, runtime, realtime. (All 2012)

[drjdpowell]

The close function won’t cause a leak if passed a previously closed or invalid reference. However, if the problem is not that the reference was closed, but instead you lost the correct open reference due to a bug in the code upstream, then that still-open reference could be a leak. So make sure the reference actually was properly cleaned up somewhere else.

[Aristos Queue]

> What other conditions could cause a close function to fail

> besides having an invalid or previously closed input reference?

That's the only one.

[GeorgeG]

Whew, that really helps me constrain my thinking about how to deal with Close and its errors.

Along similar lines I have been trying to understand what happens with the non-close primitives. Let's start with Open... if it returns an error, does that mean I am guaranteed that the open failed completely? That is, might I be left in an ambiguous partial state where some resources were allocated, but the open still failed? And is that behavior consistent? Obtain Queue, Open TCP Connection, Open VI Reference, etc

And then the VI's that do work (like enqueue, TCP write, Start Async Call, Generate User Event) return errors, does that mean that they failed completely? Is it possible the function was actually successful, but still returned some kind of error?

In a more general sense, I am trying to work out how I think about error handling down at this level. I have started to ask myself, well, if such-or-such VI returned an error, I can assume it failed, and if it failed, what should I do next. But then I started to wonder how safe the assumtion of failure (or complete failure) was, and I am not really sure how to go about testing the primitives under different error conditions. I guess this is a pretty low level question and based in paranoia, but just because I am paranoid doesn't mean the bugs aren't out to get me...

[Mellroth]

...That's the only one....

Except bugs in the Close function code ;-)

/J

[Aristos Queue]

Except bugs in the Close function code ;-)

Nope. Those don't return errors. :-)

[Mellroth]

Nope. Those don't return errors. :-)

Ouch...

/J

[Yair]

And then the VI's that do work (like enqueue, TCP write, Start Async Call, Generate User Event) return errors, does that mean that they failed completely? Is it possible the function was actually successful, but still returned some kind of error?

A long time ago, in a version far, far, away I was asked to debug an issue where a property or invoke node wasn't working properly. I think it was returning error 1, which I couldn't understand, since the only relevant input was a VI ref and it was getting that directly from the open VI ref primitive and the probe showed a value (and I think it worked for other things). It took me a while to get to the answer - the OVR prim was returning both an error and a reference and I didn't see the error because auto-error-handling was turned off and I was expecting it to be on. Once I saw the OVR error I figured out what the problem was with the OVR prim.

I really don't remember the details of what caused this, and I'm assuming that a situation where OVR returns both an error and a half-valid ref is a bug, but it looks like it still can (or at least could) happen.

P.S. It's also possible that the issue was with the open app ref primitive, but the concept is the same.

[drjdpowell]

I'm assuming that a situation where OVR returns both an error and a half-valid ref is a bug, but it looks like it still can (or at least could) happen.

Was it really “half-valid”, or just invalid but non-zero?

[Yair]

Was it really “half-valid”, or just invalid but non-zero?

Like I said, I think it worked for some of the things and not for others, but it was long enough ago and unimportant enough (it wasn't my code) that I don't remember for sure. It's quite possible that it was just a number.

The main thing that annoyed me then was that the AEH was disabled, but the error out terminal was not wired, which was what caused the error to be effectively invisible.

[GeorgeG]

So you could follow an Open with a Close-if-Error and that way you could make the open either fully succeed or fully fail. What about Enqueue or TCP write (or any of the others)? Is there a way to know whether the fuction failed completely?

[JamesMc86]

Surely the same logic can follow for these as well?

I think this whole discussion highlights the need for a solid error handling strategy. There are specific errors you can handle there and then such as a network connection failing and use local error handling such as retrying a failed opening but good central handling will catch and handle those errors that you cannot anticipate and I promise you cannot consider every error!

[GeorgeG]

...There are specific errors you can handle there and then such as a network connection failing and use local error handling such as retrying a failed opening...

I think this is what I am trying to wrap my head around. To do any local error handling I need to know what happened and what didn't happen right? If I tried to enqueue an element into a queue and I get an error from the enqueue function, I need to know what happened to the element before I try to do local error handling... local error handling shouldn't enqueue the element again if the operation was successful notwithstanding the error. Is it possible for that to happen?

I'm not talking about specific error codes here. I just want to know for sure whether the element got into (or out of) the queue. Is the presence of any error enough to definitively say nothing was enqueued or dequeued?

[JamesMc86]

I would say yes. A good API should throw an error if it is unsuccessful and an absence of an error should mean the action has been taken successfully. I would say if something didn't throw an error in this case it is a bug with the API.

If something works but extra messages are required then warnings should be used although not many of the core Apis use these often.

In terms of memory leaks I would suggest that it is bound to be possible if there are bugs however I think if you are getting repeated errors to an extent these are leaking memory then you have a different issue. If you detect the error and shutdown the application then I would argue the leak is somewhat irrelevant as it won't occur under normal working conditions.