Search code examples
vb.netmemory-leaksodbcdriverfilemaker

FileMaker's ODBC Driver doesn't release Handles (memory leak)


After a whole day tracking down a memory leak in my VB.NET project, I have traced the cause to a bug with FileMaker's ODBC driver !

To reproduce you'll need a database you can connect to (I have mine hosted on Server Advanced 11.0.3, but you can also host it locally), and the ODBC driver registered/installed on the PC (I tested versions 11.3 and 12.0, and the latest 12.2).

Start a new VB.NET WinForms project, add a button to the form and paste this code onto the button's click event:

Using cn_FM As New Odbc.OdbcConnection("DRIVER={FileMaker ODBC};SERVER=192.168.1.xxx;UID=admin;PWD=admin;DATABASE=test;")
    cn_FM.Open()
End Using

All this code does is open a connection to a FileMaker database, however if you analyse the memory usage in Windows Task Manager you can easily see (by repeatedly clicking the button you just made) that cn_FM is not being disposed properly because the Handles keep increasing! I tried forcing Garbage Collection but this didn't do anything, so I assume its a problem with the driver itself.

Oh, and I tested connecting to a SQL database in the same way, and as you would expect, there was no handle leakage...

Can anyone confirm this is correct?

Edit: I tried various ways of opening and closing the connection, as well as actually querying the database for something in the using block. Also tried hosting the fp7 file locally, but still no go :(


Solution

  • I got around this problem by making a persistent connection (declare and open it once and leave it open). But I need to check if its still open each time I want to use it, for example:

    Public Sub CheckOpen(ByRef cn As Odbc.OdbcConnection)
        If cn.State <> System.Data.ConnectionState.Open Then
            cn.Close()
            cn.Open()
        End If
    End Sub
    

    If you have multiple FM database files then this may mean you need to have one connection for each file.

    Side Note: FileMaker's xdbc_listener.exe process running on FMSA is also leaky. We have noticed a pattern that once it reaches just under 2GB memory usage it crashes. So keep in mind that the process may need constant restarting.