Objects not unmapped when shared memory is closed [CORE3067] #3446
Labels
affect-version: 2.0.0
affect-version: 2.0.1
affect-version: 2.0.2
affect-version: 2.0.3
affect-version: 2.0.4
affect-version: 2.0.5
affect-version: 2.0.6
affect-version: 2.1.0
affect-version: 2.1.1
affect-version: 2.1.2
affect-version: 2.1.3
affect-version: 2.5 Alpha 1
affect-version: 2.5 Beta 1
affect-version: 2.5 Beta 2
affect-version: 2.5 RC1
affect-version: 2.5 RC2
affect-version: 3.0 Initial
fix-version: 2.0.7
fix-version: 2.1.4
fix-version: 2.5 RC3
fix-version: 3.0 Alpha 1
priority: major
qa: cannot be tested
type: bug
Submitted by: @AlexPeshkoff
Initially reported in fb-devel by Chris <coderight at gmail dot com>:
I'm running the 2.5 RC2/RC3 SuperClassic (fb_smp_server) server on
Linux (Ubuntu 10.04 64-bit) and it never seems to release the lock
files. The count in /proc/sys/fs/file-nr just keeps going up over
time as clients connect and disconnect from the database.
If I look at the output of lsof I see the fb_smp_server process has
tens of thousands of /tmp/firebird/fb_lock_xxxx files open and it
never seems to close them even when no clients are connected to the
database. Most of the files do not exist in /tmp so I assuming
something is unlinking them but they must still be held open by
something.
Seems to happen with any client connecting to the database. To
recreate just connect isql to a database then exit and notice the
leftover lock files listed in lsof or by checking
/proc/sys/fs/file-nr.
Commits: 3ecdb30 d197111 5113a8d 9a7dd2f
The text was updated successfully, but these errors were encountered: