Bug 89981 - db4 lockers table (known bug upstream)
Summary: db4 lockers table (known bug upstream)
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: db4   
(Show other bugs)
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL: http://www.openldap.org/lists/openlda...
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-30 19:03 UTC by Phil Mayers
Modified: 2007-04-18 16:53 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-14 04:22:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Phil Mayers 2003-04-30 19:03:23 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830

Description of problem:

Berkely DB 4 has a known upstream bug apparently - see here:


I'm seeing this bug on both RedHat 8 and 9 boxes, since they both have db 4.0.14
(the emails suggest it's fixed upstream?) with db4 in CDB mode. It's a periodic
failure for my app - using bsddb3 for Python (version 4.1.3) I get:

bsddb._db.DBNoMemoryError: (12, 'Cannot allocate memory -- Lock table is out of
available locker entries')

A db_recover seems to cure this.

[I am also a bit worried that RPM will eventually fall foul of this - that would
be disastrous!]

If it's fixed upstream could a patch be backported? Alternatively (I know, I'm
being lazy) could the db4 maintainer track the Sleepycat bug ID (#6520 as
mentioned in the email above) for the fix?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run an application on a db4 database (at least in CDB mode)
2. Leave it running
3. You'll get errors about the lockers table being full

Actual Results:  Application starts crashing with:

bsddb._db.DBNoMemoryError: (12, 'Cannot allocate memory -- Lock table is out of
available locker entries')

Expected Results:  Continued running without failures.

Additional info:

The patch is linked here:


...and a different patch from Sleepycat here:


I've patched my db4 RPM and will let you know if it stays stable.

Comment 1 Phil Mayers 2003-05-10 15:16:14 UTC
The first linked patch does *not* fix the problem - I'm about to re-build the 
RPM and try the 2nd patch.

Comment 2 Barry K. Nathan 2003-05-17 10:53:51 UTC
FWIW, recent versions of RPM (4.0.5, 4.1.x and 4.2 for sure) do not use the
systemwide Berkeley DB any longer -- they use their own private copies instead.
(In the case of 4.0.5/4.1.x/4.2, it's a patched db 4.1.24, I think. Check the
RPM changelogs/documentation for more information.)

Comment 3 Phil Mayers 2003-05-17 15:24:21 UTC
Hmm. The 2nd patch didn't seem to fix it either. It's good to know that RPM 
doesn't use the system libdb - I'll probably upgrade to the 4.1 track from 
source in that case and see if it goes away - although I've rolled the machine 
back to 7.3 now!

Comment 4 taj 2004-10-02 08:09:52 UTC
Phil says:
[I am also a bit worried that RPM will eventually fall foul of this -
that would be disastrous!]

Nothing like seeing that as the first hit in google.

After performing yum install db4-devel (unrelated?) in fedora rawhide, ...
rpm -qa
rpmdb: Lock table is out of available locker entries
error: db4 error(22) from db->close: Invalid argument
error: cannot open Packages index using db3 - Cannot allocate memory (12)
error: cannot open Packages database in /var/lib/rpm
no packages


Phil also says "A db_recover seems to cure this."  would there be more
to the command line than 'db_recover?'

I assume this should be opened as a seperate bug?  I've had no
problems with rpm until I did the install of db4-devel and then this.

In fact it got a little further.  All of the following worked
 1044  yum install db4-devel
 1045  yum install gcc-g77
 1048  yum install evolution-devel gmp-devel gd-devel
 1050  yum install slang-devel gpm-devel

then bad news as seen above with

 1056  yum install  libjpeg-devel libungif-devel libtiff-devel 
zlib-devel  gettext 


Comment 5 taj 2004-10-04 05:10:55 UTC
Filed comment 4 as a new bug.


Comment 6 Jeff Johnson 2004-11-14 04:22:36 UTC
From my (recent) exeperience with a db lockers table full problem
in rpm, the issue was not closing cursors and databases,
causing table overflow eventually.

The defaults should be sufficient for general purpose
use, that's certainly the case within my rpm experience.

If OpenLDAP is an exception that truly needs a larger table,
then pleas reopne this bug and get confirmation that, indeed,
OpenLDAP needs more table entries.

Note You need to log in before you can comment on or make changes to this bug.