Memory Leak on Database Reopen

jpc · November 17, 2007

We are experiencing what we believe is a memory leak in Labview 7.1 when attempting to open and reopen an ODBC connection to a SQL database.

I have seen this topic mentioned in several places...

http://forums.lavag.org/Memory-Leak-t9438.html

http://forums.lavag.org/Memory-usage-issue...lkit-t6570.html

http://forums.ni.com/ni/board/message?boar...essage.id=53391

...but, the problem resolution seems to be to just open and close the connection once. OK, you lose 4K of memory and no big deal.

But in our case, we have a control system reading and writing to a SQL database at regular intervals, and would like to re-establish that connection automatically if it becomes broken (server crash, maintenance, backups, etc.). So the app was designed to loop every few seconds trying to reconnect. We wrote the code, it works well unless the server is down for extended periods of time. Then we noticed the app crashes from depleted memory. We isolated the problem to an open/close connection problem just like in the links above.

So my questions are:

Has this been confirmed to be a Labview problem?

Or is it a ODBC problem with SQL?

Does anyone know if NI has ever addressed this issue?

And, yes, we have a workaround in place. The error is flagged and an operator must manually reconnect when the server is determined to be back online. We cannot risk crashing the control system. We would like to go back to the automatic reconnect, but I still haven't seen this memory leak problem resolved. My colleague who wrote code claims Labview 8.5 still has not fixed this problem.

-John

bbean · November 17, 2007

QUOTE(jpc @ Nov 16 2007, 05:53 PM)

We are experiencing what we believe is a memory leak in Labview 7.1 when attempting to open and reopen an ODBC connection to a SQL database.

Can you post the code where the DB is called?

Val Brown · November 17, 2007

QUOTE(jpc @ Nov 16 2007, 02:53 PM)

We are experiencing what we believe is a memory leak in Labview 7.1 when attempting to open and reopen an ODBC connection to a SQL database.
<snip>

My colleague who wrote code claims Labview 8.5 still has not fixed this problem.

John:

As far as I know, your colleague is correct: ie, this problem has persisted into v8.5. And so has the recommended work around, viz, only perform the open operation ONCE and then pass the reference around in shift registers...

jpc · November 27, 2007

I decided to dig into this problem a little deeper to see if I could find the source of the memory leak.

I discovered that opening and closing the ODBC connection alone does not generate a leak. The leak did not occur until I inserted a table read in between the open close. I thought this was odd, because the error cluster generated on the failed open should pass through the read VI aborting its execution. However within the read VI (DB Tools Select Data.vi) is a subVI called DB Tools Error Helper.vi that is executed regardless of whether an error is passed in or not. The memory leak is occurring in this Error Helper VI when processing an error.

I am attaching the test program VI I used with Windows XP SP2, Labview V7.1, and the Database Connectivity Toolkit, which to my understanding has not changed through several Labview revisions. After setting up an ODBC connection to a SQL test database, I run the program and make sure the table can be read with no errors. To check the memory usage, I run the Task Manager and monitor the Commit Charge value.

To simulate a server crash, I unplug the network connection. The Commit Charge value initially jumps, then stabilizes, as the ODBC breaks and the error is realized and displayed. With the switch set to skip the DB Tools Select Data.VI when an error occurs, there is no growth to the Commit Charge memory value. Toggle the switch to allow the error cluster to pass through the Select Data.VI and the memory grows by 4K per loop iteration.

To confirm the leak in the Error Helper.VI, I commented out its use in the DB Tools Select Data.VI (see the 2nd attachment) and reran the test. No memory growth.

I didn't dig any deeper into the Error Helper.VI to find the error source. It does call the "Call Chain" Labview primitive to get a list of all the VIs for reporting errors, perhaps it's in there. The Error Helper.VI is called by quite a few other VIs in the Toolkit, but not the open and close connection VIs, which explains why my initial test results seemed odd (and probably a lot of other things too).

Since our app is running on embedded PCs, commenting out a display routine will serve as a workaround until a fixed version of the Database Connectivity Toolkit comes out.

I hope this helps those who have been frustrated with this problem.

-John

jpc · November 27, 2007