Memory leak in embedded server
------------------------------
Key: CORE-6067
URL: http://tracker.firebirdsql.org/browse/CORE-6067
Project: Firebird Core
Issue Type: Bug
Affects Versions: 3.0.4
Environment: Windows 10, Firebird 3.0.4.33054 x64, embedded,
SuperServer
Reporter: Tobias Zipfel
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
