Issue Details (XML | Word | Printable)

Key: CORE-4209
Type: Bug Bug
Status: Open Open
Priority: Critical Critical
Assignee: Unassigned
Reporter: Roque
Votes: 0
Watchers: 5
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Firebird memory not released (Using superserver) *Linux*

Created: 05/Sep/13 03:43 PM   Updated: 06/Sep/13 01:20 AM
Component/s: Engine
Affects Version/s: 2.5.1, 2.5.2 Update 1
Fix Version/s: None

Environment:
Linux Ubuntu 11.04 32 bits
FirebirdSS-2.5.2.26540-0.i686


 Description  « Hide
This bug is the exact same bug description found on http://tracker.firebirdsql.org/browse/CORE-3533 but now on Linux.

Memory is *only* freed when all users disconnect. To reproduce it, just follow the simple procedure below:

- Open an ISQL session or an instance of any application using FB. (This session will be the last one to be closed)
- Try working with others instances of the same application or open several ISQL sessions using the same DB. Make some heavy operations.
- Keep checking the memory every time. (use 'top' command or 'ps axl | grep fbserver')
- Close all instances, except the first one.
- Check the memory. It is *not* released as it should.
- Now close that ISQL session you opened in the beginning.
- Check the memory. Now it is all there, given back to the system.

I can supply additional information and made additional tests if needed.

Thanks.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dimitry Sibiryakov added a comment - 05/Sep/13 03:53 PM
As designed. There is no point to release memory. Especially in superserver.

Roque added a comment - 06/Sep/13 01:15 AM - edited
You cannot hold memory until exhaustion, it is a bad design. I use FB since version 1.0 and I noticed that bug from version 2.5 onwards. In #CORE-3533 this behaviour was declared a bug, why now would it be different?

I have a server running v. 2.5.1 that crashes after few weeks. I have to permanently restart the service before it happens, with the version 2.0.x I never did that.