[#CORE-3067] Objects not unmapped when shared memory is closed

Firebird Core

Objects not unmapped when shared memory is closed

Created: 09/Jul/10 10:59 AM Updated: 04/Feb/11 12:12 PM

Component/s:

None

Affects Version/s:

2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.1.0, 2.0.4, 2.5 Alpha 1, 2.1.1, 2.0.5, 2.1.2, 2.5 Beta 1, 2.5 Beta 2, 2.1.3, 3.0 Initial, 2.5 RC1, 2.5 RC2, 2.0.6

Fix Version/s:

2.5 RC3, 2.1.4, 2.0.7, 3.0 Alpha 1

Time Tracking:

Not Specified

Environment:

Any posix 64-bit environment, except HPUX.

Planning Status:

Unspecified

Description

« Hide

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.

All

Comments

Work Log

Change History

Version Control

Subversion Commits

Sort Order:

[ Permalink | « Hide ]

Alexander Peshkov added a comment - 09/Jul/10 12:54 PM

Masking 64-bit pointer with 32-bit mask was really bad idea - with Object == 0x7FAB12345678 and page size == 4K, we were getting starting address 0x12345000 instead of desired 0x7FAB12345000 (upper bits were lost).