Potential Memory Leak with Notifiers

user_2607201 0
Viewed 296

Running the Desktop Execution Trace Toolkit, I've noticed some strange behaviour.

Tracing the memory allocation has pointed out some strange behaviour that seems to me like a leak.

Picture of trace and test vi here => enter image description here

On obtaining a notifier, memory is allocated (once or twice, depending on circumstance) and freed (either not at all or once) meaning every notifier obtained is one block of memory allocated and not freed. This could be the cause of a bug in our code running over a long period of time using lots or obtained and released notifiers. Is this is known behaviour and the allocated memory is freed automatically outside of the scope the trace or is this a genuine low impact memory leak?

labview memory-leaks
1 Answers

Based on the provided example it is hard to tell whether there is really leakage, because it is not seen sequence of buttons used (Create and Destroy). Did you send data in between? Did you release it right after Create, all the time? Could you post the VI which you test and describe how do you exactly test it?

If notifier is created once, and then released - then no memory allocation occurs, check the image below.

So in your case there are some additional events happening, which cause memory allocation. And, implementation of the code as FGV (or action engine) could help to eliminate such an issue, because you will be sure that reference is opened just once, and then just reused. Memory leaks will occur when reference is opened multiple times, but is closed less times. Another point - dynamical allocation of buffers in LabVIEW is usual thing, and could happen because of different reasons. But LabVIEW compiler is smart enough to handle such buffers, so usually no worries about that. Buffers are allocated, then flushed, etc. Just make sure that references are always closed - because main reason of LabVIEW memory issues is not released references. Notifiers trace

user_69174460
Related