PWCTRL.FP and memory

[benoitb]

HI,

I use the instrcument driver 'PWCTRL.FP' with CVI 8.0. When i use the funciton 'PasswordCtrl_Create' or the function  'PasswordCtrl_ConvertFromString', some memory are not freed when i close my application, event though i call the function'DiscardCtrl()' before the DiscardPanel().
 
ExAmple  :
void main( void ) {
 INT32 panel, new_pw, old_pw, confirm_pw;
 UINT32 nb_blocks, nb_bytes;
 
 panel = LoadPanel( 0, "C:\\Logiciel\\BCTESYS\\Password\\password_uir.uir", CONFIGURE );
  /* ctrl en type password */
 old_pw = PasswordCtrl_ConvertFromString (panel, CONFIGURE_OLD);
// new_pw = PasswordCtrl_ConvertFromString (panel, CONFIGURE_NEW);
// confirm_pw = PasswordCtrl_ConvertFromString (panel, CONFIGURE_CONFIRM);

 DiscardCtrl( panel, old_pw );
 DiscardPanel (panel);
 // For memroy checking

CVIDynamicMemoryInfo( "", &nb_blocks, &nb_bytes, 0 );
 if ( nb_blocks || nb_bytes ) {
  char message[255];
  sprintf( message, "Memroy\nNb blocks : %u\nNb bytes : %u",  nb_blocks, nb_bytes );
  MessagePopup( "Surprise", message );
 }
 return;    
}
 
=> With this code , i always get 2 blocks and 80 bytes not freed !

Anyone can help me to use this NI driver ?

[MJF]

Interesting problem... I have not seen this before though I have used the password control before.

The good news is that the source code for this is available in the toolslib\toolbox\custctrl directory. You could add breakpoints to it to see if you can figure out what is happening.

A cursory look at the code shows that when the control is created, a data structure with various parameters for the control including a buffer for the obscured text and the length of the text is allocated using calloc. The control callback has a section for EVENT_DISCARD that calls a function that is supposed to release that data structure and free the memory. Without spending some time digging deeper, I don't see anything obvious that would create the leak.

[MJF]

I just couldn't leave this alone so I did a bit of digging.

It turns out that those two blocks of memory are allocated during a call to ChainCtrlCallback(). They are not subsequently removed after a call to UnchainCtrlCallback() where I would expect this to get cleaned up. Looks like you uncovered a memory leak bug, not in the password control code but in the UIR library.

I am attaching the output from an edited version of the example above and the pwctrl.c source file using CVIDynamicMemoryInfo() to snoop the state of the memory allocation at each step in the process of creating and destroying the control.

[LuisG]

Martin,

You are correct. Those blocks are allocated as part of the callback chaining, but this is not a memory leak. The first time that a control in any panel has its callback chained, CVI needs to allocate some memory in order to manage the callback chaining for this panel. This memory is not freed as soon as a callback is unchained, because it belongs to the entire panel, not each individual callback node. But it is freed when the program exits, via the use of the atexit() mechanism.

This memory is allocated on a one-time basis, so it is not being cumulatively allocated. You can confirm this by repeatedly creating and discarding password controls in a loop. For example:

while (i++ < 10)
{
ctrl = NewCtrl (panel, CTRL_STRING, "test", 0, 0);
old_pw = PasswordCtrl_ConvertFromString (panel, ctrl);
DiscardCtrl (panel, old_pw);
}

With this code, it should be the case that the allocated memory never grows beyond those 80 bytes.

By the way, the callback chaining mechanism isn't really part of the UI library. It is implemented in the Programmer's Toolbox, which is open-source (see toolslib\toolbox\toolbox.c). If you look at the code, you can see where this allocation is made (RecordPanelWithLinkedCallback) and then freed (DestroyPanelsWithLinkedCallbacksList, called from ObjectDeletionProcedure).

Hope this helps.

Luis

[MJF]

Thanks Luis, that is good to know.

I had thought the callback chaining was part of the UI library but I have been known to be mistaken once in a while.