Memory leakage when using Ini-file VIs

[Mads]

I'm using the Configuration File Vis to read and write data to different .ini files. The files contain both standard keys and clusters written as a segment using the Open G toolkit. Instead of opening the files and keeping them in the memory of the Config VIs I'm just using them to read and write, decode and encode...the references are all closed using the Close Config Data.vi. The problem is that even though immediately close the config data the application keeps grabbing more and more data...every time a configuration file is open, read or written to and the closed everything from 4K to 50K of additional memory has been allocated by the application (this is a stripped down application that only deals with the config files, so
there are no other sources for the memory leak).

Has anyone else experienced this? How can you repeatedly open and close config file slike this without it continoulsy allocating more memory?

Attached is a copy of the VIs, the directory structure must be kept intact if the ini file is to be read correctly.

I've been stearing so hard on this the whole day that I might just be overlooking something obvious...

In the full application the VI init and write operations are only done when the user reconfigures the system, which may be a couple of times per month...so the memory leak would not cause a problem right away, but it would not be healthy to leave it there...

[Ben]

Could you post a 6.1 version?

LV7 is still about two weeks away for me.

Does the problem show up in 6.1?

I ran across an error while writting to a FP output that was not configured that would cause a "drop of memory" to leak every time the VI performed the write. The leak did not show up in the profiler but windows would show te memory foot print growing continually as long as the writes continued. The work around was "don't do that!".

I bring this up because I found and reported this just prior to LV7 release and the featur may still be present in LV7. I also believe that Jean-Pierre used a "write and check" metod to detail with the unknown data types of of complex data structures.

If you just read does it leak?

If you just use simple data types do
es it leak?

Is the ini file growing?

I really appreciate the effort you have been putting into the Dev-Exchange Mads! I wish i could do to more to help.

Keep us posted.

Ben

[Ben]

Correction:

I also believe that Jean-Pierre used a "write and check" method to deal with the unknown data types of of complex data structures.

[Mads]

Thanks Ben, I've got a long way to contribute as much as you have:-)

Attached is a 6.1 version. The .ini file does not grow. I have focused on the reading part so far, but the write part leaks as well. Cutting out the complex data types greatly reduces the leak, but it's still there...

The VI to run is called Leak Demo.vi. I have built an application of it when testing it, it starts off allocating > 800 KB of memory the first 8 minutes on my XP machine with LV7, haven't tested it under LV6.1.

[Ben]

The demo does not leak in the development environment under LV 6.1!

To support the complex data types, control refnums are being opened and closed. I still believe that these resources are not freed-up until LV exits.

That would explain the reduection in the leak rate when they are avoided.

Gotta get back to work now! I will watch for updates,

Ben

[Mads]

Fetched a machine with 6.1 and built an application there. The 6.1 application has a stable memory usage from start, the LV7 application allocates memory continously after startup. The memory allocation slows down after a couple of minutes, but still...the LV7 version does not look healthy (The LV6.1 application requires almost 2 MB less memory as well...but that's probably the way thing go these days...).

It's not so long ago since I started a thread here discussing why applications would grab more memory everytime another application was started.

This one might be of interest for NI as well...

Thanks Ben:-)