When executing read queries against 3.0.4.33054 as embedded server we experienced constantly growing values for private bytes.

We originally realized the growing memory consumption in a larger application when running actions resulting in many database reads.

For easier testing purposes we used a simple C# program (source in attachment) with the .Net driver (https://firebirdsql.org/en/net-provider/) version 6.6 to test.

- 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-3.0.5.33126-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.