You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This bug is the exact same bug description found on CORE3533 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.
The text was updated successfully, but these errors were encountered:
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 #CORE3533 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.
description: This bug is the exact same bug description found on CORE3533, 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.
=>
This bug is the exact same bug description found on CORE3533 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.
Submitted by: Roque (rroque6428)
This bug is the exact same bug description found on CORE3533 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.
The text was updated successfully, but these errors were encountered: