- The read queries are run against the example EMPLOYEE database from the Firebird installation folder.
- We used the default firebird.conf and only change the server mode.
- connection, command and reader are used in "using" blocks to trigger disposing.
We tested the following conditions all having the same problem:
- latest nightly build (Firebird-22.214.171.124126-0_x64)
- .Net driver 6.5, 5.12
- SuperClassic, SuperServer
- reusing the same connection and commands objects
- calling FBconnection.ClearAllPools after each read
The memory leak disappeared for the following conditions:
- Run Firebird 3.0.4 as dedicated server. Both applications (test program and the Firebird server) have a constant amount of private bytes.
- Run Firebird 2.5 with driver version 6.6 as embedded server.
We used Microsofts Debug Diagnostics tool to create reports of the memory consumption (see attachment).
The report contains analysis of three memory dumps (.Net and native) taken at different points in time.
Here you can see that in the last snapshot the allocations in fblclient have grown a lot.
Maybe the call stack information in the last memory dump report can help somehow...
From these reports and results we got with pure .Net memory analyzers you can see that the .net heap is constant over time.
Do we miss something here?
Is this behavior configuration dependent? Or is there something else wrong about how we use the driver?
Is this maybe rather a driver problem?
We are glad to help if more information/testing is required.
Sean, your statement is not entirely correct. The "op_prepare" happens implicitly in this case, because it was not called explicitly. Also at the end of the `using` block, the statement is released on server by sending "op_free".
I have to try to run the program myself to see what's what, but from the code POV, nothing looks wrong.
The problem is because provider first commits transaction and then closes cursors opened within it.
fbclient should be ready for such case but massive refactoring in v3 introduced memory leak of cursor object (YResultSet) in this scenario.
Looking for the fix in fbclient.
Suggest to fix provider code too.