|
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. Vlad, by closing cursor you mean op_free_statement (if I'd talk network protocol)?
Jiri,
in this *embedded* case i speak about isc_dsql_free_statement. It is called after isc_commit_transaction. If speak about network protocol - yes, you correct: op_free_statement passed by client to server to close cursor and\or drop statement at server side. Description changed to better reflect nature of issue.
Note, this memory leak happens when both conditions are true: - application works with ISC API - cursors (result set) is closed after transaction is committed (rolled back) Tested the nightly build, no more memory leaks.
Thanks for the quick response and fix! |
So, it is creating a *new SQL statement* with each program loop, as such new memory would be allocated for the new statement.