Memory leak at X64?

[wassi]

Hi all,

i am using CVI2019, trying to convert a 32 Bit program to 64 Bit, windows10, building an exe and run on external machine. The program works well in 32 Bit. I did modifications according to NI-recommendations. Have no Compiler Errors or warnings.

When i run the program in X64, after some time(2hours), memory starts to fill up continously with 4k blocks every ~5 secs. I have already removed nearly everything from the program and do now only display the current time in a text-Display updated by a 50 MS-timer, using functions TimeStr(), DateStr(). There is no malloc or similar in Code. But Problem stays ahead. Looks like that speed of memory rise is depending on speed of timer.

Thats the code of timer function:

int CVICALLBACK UANZEIGE (int panel, int control, int event, void *callbackData, int eventData1, int eventData2)
{
char text[25];

if (event == EVENT_TIMER_TICK)
 {
 Zeitformat(text);          // Uhrzeit
 SetCtrlVal (panel, START_ZEIT, text);
 }
return 0;
}

void Zeitformat (char text[])
{
char *date, *zeit;

zeit = TimeStr(), date = DateStr();
Fmt (text, "%s[w21q]<%s[w4]%s[w1]%s[w5] * %s", date+6, date+5, date, zeit);
}

Is there somobody who had similar experience?

[carlox]

May be it's some reentrancy problem on your timer callback. I have not the time to write and test a similar code on my side, also because this is easily a non duplicable issue on different hardware, CPU speeds, and so on.

Anyway you should note that is absolutely meaningless display the current time, that varies every second, at 20 Hz, and relaxing this frequency could fix the problem.

If this high frequency is a leftover of the full code of your application, and you really need to have a timer so fast, the usual suggestion in this case is to use an Asynchronous Timer, to run the timer callback in separate thread, and decouple all the GUI related code in one (or more) functions called by PostDeferredCall, that will be executed in the context of GUI thread. 
To use PostDeferredCall you need to allocate a buffer to pass the values to the deferred function, and remembering to free it in the function, of course.
Of course you shoud decimate the GUI updates to a more realistic frequency, given the needs of your GUI, and the nature of data displayed (i.e. 1 Hz for the clock sample).
For example, in some code of mine, I have a deferred callback at 1 Hz for numeric fields update, another one at 10 Hz for a "real time" strip chart, while the main thread runs at 100 Hz, reading data from a source and inserting @ 10 Hz in a thread safe queue.

PostDeferredCall does queuing on its own, and it's not a good idea to let this queue grow too much, for the obvious effects on GUI updating.

[wassi]

Thanks for your answer carlos,

as you assumed allready this fast timer calls are only for testing. In the full program i run the timer for the GUI with 1 Hz or even at longer interval. The reason for the fast call is to make the effect clear visible, without having to wait for several days. With slower calls it takes only more time to fill up the Memory, but it happens in the same way.

For the "real" program i use a program similar to your description with a timer in a 2nd thread for reading and handling the data. In that program i saw the failure with memory leak first. So i tried to find whats going on with different modifications and cut off different parts of the Code until i came to this short part which shouldn't make problems at all. So i assume that this failure happens on all 64Bit Code. But Maybe is not detected on programs which run only for a short period of time.

I have tried this simple code on different machines with the same result.

I have also tried to chek the stack-size by testing the adress of a temporare variable without result: the temporar variable stays at the same adress in each function call.

For my understanding, the interesting point is, that all the code works perfectly when it is built as 32Bit code. The failure happens only when the code is built for 64Bit.

[carlox]

I've understood.
All I wrote was related to the hypothesis that the problem could be related to a bug of x64 code, that occurred at high frequencies of calling, due to some form of not-reentrant code or something similar.
If it happens at 1 Hz  or less, clearly this is not the case.
Can you send me your stripped down program, so I will test here, too? 

[wassi]

Hi Carlo,

this are the files, Thanks a lot.

Erich