Issue Details (XML | Word | Printable)

Key: CORE-3067
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Alexander Peshkov
Votes: 0
Watchers: 0

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

Objects not unmapped when shared memory is closed

Created: 09/Jul/10 10:59 AM   Updated: 20/Jul/15 05:21 AM
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

Environment: Any posix 64-bit environment, except HPUX.

QA Status: Cannot be tested

 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

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

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
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).