Memory Leak

[ScadaMan]

Has anyone ever experienced "memory leak" problems in applications involved with Database systems ?.

This occurs when we used database connectivity toolkit in LabVIEW8.20 to conncect to Oracle10g RDBMS installed at a server. At first everything is ok, but after a while, memory usage of the server tends to be increasing. We rechecked our code several times and nothing in the code seems to be the cause of the problem. We, however, suspect the functionality blocks of the DB connectivity tools.

Thank you very much.

[LAVA 1.0 Content]

QUOTE(ScadaMan @ Nov 1 2007, 10:03 AM)

Has anyone ever experienced "memory leak" problems in applications involved with Database systems ?.

This occurs when we used database connectivity toolkit in LabVIEW8.20 to conncect to Oracle10g RDBMS installed at a server. At first everything is ok, but after a while, memory usage of the server tends to be increasing. We rechecked our code several times and nothing in the code seems to be the cause of the problem. We, however, suspect the functionality blocks of the DB connectivity tools.

Thank you very much.

Yes I have. There is a long thread about this : http://forums.lavag.org/Memory-usage-issue...lkit-t6570.html

To sum up, you must not "open", right/read and close everytime because the 4k reference is released only when LabVIEW shuts down.

You have to do a single open, keep the reference in shift register and close this reference only when you quit your application.

Hope this helps

[ScadaMan]

QUOTE(TiT @ Nov 1 2007, 04:09 PM)

Yes I have. There is a long thread about this : http://forums.lavag.org/Memory-usage-issue...lkit-t6570.html

To sum up, you must not "open", right/read and close everytime because the 4k reference is released only when LabVIEW shuts down.

You have to do a single open, keep the reference in shift register and close this reference only when you quit your application.

Hope this helps

Thank you very much, TiT.

I will try your suggestion.

[Helmer]

QUOTE(ScadaMan @ Nov 1 2007, 04:03 AM)

Has anyone ever experienced "memory leak" problems in applications involved with Database systems ?.

This occurs when we used database connectivity toolkit in LabVIEW8.20 to conncect to Oracle10g RDBMS installed at a server. At first everything is ok, but after a while, memory usage of the server tends to be increasing. We rechecked our code several times and nothing in the code seems to be the cause of the problem. We, however, suspect the functionality blocks of the DB connectivity tools.

Thank you very much.

I have noticed the same

[bbean]

Is this happening on the server side? Are there any LabVIEW applications on the server?

Many Database Servers, MS SQL Server for example, will hog memory up as they go. The memory won't be released by the DB until another application requests it. I believe they do this so they can store queries and frequently executed statements in memory for faster exection. Check to see if the Oracle DB has some way of limiting the maximum amount of memory it uses.

Regards

[Wolfram]

Hi folks,

attached I have a VI that produces a memory leak. It works ("misworks") in LabVIEW 8.6 and 8.5/8.5.1 but not in LabVIEW 8.2. The attached VI is saved in LabVIEW 8.5.

Wolfram

[TobyD]

QUOTE (Wolfram @ Nov 18 2008, 05:54 AM)

Hi folks,

attached I have a VI that produces a memory leak. It works ("misworks") in LabVIEW 8.6 and 8.5/8.5.1 but not in LabVIEW 8.2. The attached VI is saved in LabVIEW 8.5.

Wolfram

I can confirm it (LV8.6 on Vista) but I can't explain it. Did you send this to NI?

[Aristos Queue]

QUOTE (TobyD @ Nov 18 2008, 12:47 PM)

I can confirm it (LV8.6 on Vista) but I can't explain it. Did you send this to NI?

Reported as CAR 134006.

[TobyD]

QUOTE (Aristos Queue @ Nov 19 2008, 12:48 PM)

Reported as CAR 134006.

:thumbup:

[brian]

Fixed in a future version of LabVIEW whose existence I can neither confirm nor deny.

The problem was the "reset to default value" caused by the unwired case structure's output in one case. The reset to default forgot to deallocate whatever was in the waveform before (the array and variant).

Wiring in an empty array of waveform constant doesn't relieve the problem; it still looks like a reset to default. However, if you allocate the array to contain one waveform (even if that waveform is empty), we stop leaking memory.

Brian

[TG]

QUOTE (brian @ Nov 21 2008, 11:46 PM)

Fixed in a future version of LabVIEW whose existence I can neither confirm nor deny.

The problem was the "reset to default value" caused by the unwired case structure's output in one case. The reset to default forgot to deallocate whatever was in the waveform before (the array and variant).

Wiring in an empty array of waveform constant doesn't relieve the problem; it still looks like a reset to default. However, if you allocate the array to contain one waveform (even if that waveform is empty), we stop leaking memory.

Brian

Oh boy good to know this and thanks for reporting!. Is it limited to waveform types only? (hopefully)

[TobyD]

QUOTE (brian @ Nov 21 2008, 03:46 PM)

Fixed in a future version of LabVIEW whose existence I can neither confirm nor deny.

That's a pretty quick turn-around time. Thanks for the explanation!

Toby

[brian]

QUOTE (TG @ Nov 23 2008, 02:57 PM)

Oh boy good to know this and thanks for reporting!. Is it limited to waveform types only? (hopefully)

To my knowledge, yes. It was in a section of code that only serves what we call "measure data" types. These are waveforms (analog and digital), the time stamp, and the Express Dynamic Data Type (which I call the "DDT" for more than one reason ).

The time stamp has nothing to leak--it's just a 64.64 fixed-point value with no strings or arrays to lose track of. All waveforms and DDT should exhibit the problem, though.

Brian