LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

NIReport_FreeMemory incomplete cleanup

Solved!
Go to solution

In the function NIReport_GetPrinters function panel online help, there is a sample code as shown below:

 

 

void GetAndFreePrinters (void){ char **allPrinters; char **printer; NIReport_GetPrinters (NULL, &allPrinters); printer = allPrinters; while (*printer != NULL) NIReport_FreeMemory (*printer++); NIReport_FreeMemory (allPrinters);}

 

I used this code in my project and I started to receive run-time errors during other memory deallocation functions like free, Ini_Dispose.

 

To investigate, I used the ResourceTracking utility to see the memory status.

I found out that after the final NIReport_FreeMemory call in the code above, a memory block of 80 bytes stays unfreed (I have 3 printers installed, NIReport_GetPrinters function allocates 5 blocks of memory in my PC).

Probably this remnant block confuses memory allocation operations and causes some other irrelevant memory free operations to fail.

 

When I say run-time error, I mean the non-fatal error "Attempt to free pointer to memory not allocated by malloc or calloc".

It looks this problem is addressed also in this thread many years ago, but it seems to stay unsolved.

 

Can you reproduce the behaviour in your PCs? (I'm working on a XP SP3 and problem is observed both in 8.5.1 and 9.0) 

 

S. Eren BALCI
IMESTEK
0 Kudos
Message 1 of 4
(4,064 Views)
Solution
Accepted by topic author ebalci

Hello ebalci - 

 

I was able to reproduce this on my machine.  It turns out we do have a little bit of a memory leak in the implementation of NIReport_GetPrinters.  

 

I have created a bug report for this issue (ID 197427).

 

As long as this function (NIReport_GetPrinters) is not called repeatedly, the leak should be of little consequence (the leak occurs once per call of the function, and the size of the leak depends upon how many printers you have installed).  I'm inclined to think the leak is not the source of the errors you are receiving, but I would be happy to take a look at some code with you if things continue to look otherwise.

 

NickB

National Instruments 

Message 2 of 4
(4,054 Views)

Hi Nick,

 

Thank you for filing a report for the issue. That could have been solved already in 2003 if the post I linked drew some attention.

 

BTW, you are right about the run-time error cause.

It was due to my incorrect use of an IniFile function.

 

I was about to let go of the error since it was non-fatal (not displayed in release mode) and I could not solve it with my 8.5.1 installation.

Then I read about the resource tracking tool and decided to give it a try.

 

At the first use, it helped me find my mistake and catched a nasty bug.

That is one powerful tool! 🙂 

S. Eren BALCI
IMESTEK
0 Kudos
Message 3 of 4
(4,009 Views)

Hey ebalci - 

 

You're right - looks like the ball was dropped on that original post.

 

I'm glad you have found the resource tracking window to be such a valuable tool.  We've found it to be very helpful internally as well.  It made tracking down this particularly tricky memory quite easy  🙂

 

NickB

National Instruments 

0 Kudos
Message 4 of 4
(3,959 Views)