Run-time Moveable Control resource leaks

[tstanley]

Hi,

I've noticed a small resource leak issue with the Run-time Movable Control library (movectrl.fp).  The issue comes up when a control is made movable, then later the MOVECTRL_ATTR_ENABLED attribute is set to 0 to make the control non-movable, and then the control is discarded, either directly or by discarding the panel that the control is on.  

Diving into the source code for the instrument, the reason is clear.  In the callback function DynamicCtrlCallback(...) which is chained to the control that is made movable, the first thing that happens is a check that the movable attribute is set, and if not, the function bails out with an early return.  The problem is that after this there is the handler for EVENT_DISCARD, that frees up the resources used by the movable control.  The problem is that if the movable attribute is not set, when the control is discarded the handler for the EVENT_DISCARD is never reached and therefore the resources are not freed.

I thought I would post this to let anyone using the Run-time Movable Controls library that as a workaround you should set the MOVECTRL_ATTR_ENABLED to enabled before discarding a movable control as to not leak memory.  And so that hopefully NI can fix this in a future release .

Thanks.

[JasoNI]

Hi tstanley,

Do you have a simple example of code that demonstrates this issue? It would help streamline the reporting process if you had one available. Thank you for your help!

Regards,

Jason D

Applications Engineer

National Instruments

[tstanley]

Hi Jason D,

No problem.  I've attached a small application. It has a button that generates a pop up with some controls on it.  It uses MakeMovableCtrl(..) to set all the controls movable, and then SetMovableCtrlAttribute(..) with MOVECTRL_ATTR_ENABLED set to 0 to make the graph control non-movable.  If you simply close the pop up (which discards the panel), in CVI's resource tracker there is some allocated memory that is not freed and a thread lock that is not discarded.  The switch on the pop up can be toggled to make the graph control movable again via SetMovableCtrlAttribute(..).  If you toggle the switch and then close the pop up you'll see that the memory is freed and the thread locks are properly discarded.  If you open/close the pop up multiple times without toggling the switch you'll see multiple blocks of non-freed memory and multiple non-discarded thread locks.

Thanks for looking into this.

[JasoNI]

Hi tstanley,

This was reported to R&D (CAR # 410989) for further investigation. The example really helped make reproducing the issue easy. Thanks for the feedback!

Regards,

Jason D

Applications Engineer

National Instruments