File Write Memory Leak in Labview Realtime (Pharlap)

[stubon]

I am running Labview Realtime on a PXI controller.

My application writes an array of waveforms to a datalog file using the Labview functions: Create a new File, write to it then close it.
This vi is triggered every 10mins and the file size is ~96MBytes.
Everytime the vi is called is uses up some memory. When the vi closes though, it doesn't release all of tis memory so that after a certain amount of calls all the RAM is used and the Controller crashes with a Fatal out of memory error.

The code works in Labview run on my pc (WindowsXP) so I think it is a problem with RealTime and probably the underlying Pharlap OS.

Does anyone know how to force the memory to be released, or another way round this problem?

Thanks

[chrisger]

hi

can you please post some code or screenshots?

best regards
chris

[cs42]

Hi,

just reading my crystal ball: you're using dynamically resized arrays? ... Yes? That's always bad on a RealTime System because it may lead to memory fragmantation and with that to a memory leak -- the code could work on a PC (not RealTime) nicely, though (because the memory managment takes care of the fragmentation).

If you can't post your code, look to this (and other things -- AFAIR there's a nice manual on what (not) to do if programming for RealTime).

Regards,
Carsten

[stubon]

Thanks guys

All my arrays are intitialised, but I am using queue's (not RealTime FIFOs) that are dynamically sized.

Two reasons for using normal queues:
I am using waveforms with single precision floating point y-representation which RT FIFO's don't support.
My channels are at different sample rates where real time FIFO's require fixed length y-array's.

The thing is:
When I take the file writting part out of my code, it works fine with the queues.
It is only when I include it that it runs out of memory.

I have tried to create a simple example that uses queues of the same length and writes files, BUT the simple example works, and my code doesn't

This suggests something else has gone awray in my code, but as I said, it does work when I remove the file writting part.

My code that produces this error is too big to post, and my sample doesn't demonstrate it.

I will go through all my arrays and double check they aren't dynamically sized.

Do you think it is it worth implementing my own queues using a recursive vi with a fixed length array, keeping track of where I am writting and reading and writing stuff out of it?

Thanks for your comments so far,
If anything else appears through the mist of your crystal ball I'd appreciate your advice

Stuart

[cs42]

Well, if having problems due to fragmentation of the memory almost *anything* can trigger the problem. That's why such issues are often found late, because you add a scmall feature thinking it's save, but afterwards the problems may start...

So the normal queues may lead to a small fragmentation. Maybe you won't notice this for a long time without any other code interfering (the code needn't to be related neccessarily!), because it's just a small fragmentation. But as the file writing seems to handle quite a amount of data (array? strings?), the fragmentation starts to get serious and you'll experience problems quickly. Maybe even the file writing routine (or things you're doing around) aren't RT save and lead to fragmentation too.

One problem I always have in LV RT is, that following the NI documentation, a string is an array of char, or better something like *char, that means a *dynamical* array of chars. If that's true, even an extensive use of strings and string operations may lead to problems! Unfortunately you can't define fixed chars in LV...

Regards,
Carsten

(There's a reasen, that NI recommends just using RT queues in a RT environment...)