Wind River Support Network


LIN6-10033 : CLONE - RPM locks up rpmdb: BDB2034 unable to allocate memory for mutex

Created: Jun 18, 2015    Updated: Dec 3, 2018
Resolved Date: Jul 6, 2015
Found In Version: 6.0
Fix Version:
Severity: Standard
Applicable for: Wind River Linux 6
Component/s: Userspace


Customer did a good number of power-pulls in response to a system freeze problem, but these errors also occur following a power-loss for any other reason, even during simple RPM read operations (such as rpm –qi gen4os). These problems do not only occur following a write operation.

We are seeing three categories of rpmdb errors:

1) Rpm locks up and never returns when an rpm/yum command is issued (DE47121)
There is no output. We’d like help understanding why this happens and why rpm does not auto-recover.

2) An Rpm/Yum command fails with “rpmdb: BDB2034 unable to allocate memory for mutex; resize mutex region“ or some other error (DE48187)
In response to issuing an rpm command, the command returns with output like the following:
rpmdb: BDB2034 unable to allocate memory for mutex; resize mutex region
error: db_init:db3.c:1087: dbenv->open(12): Cannot allocate memory
error: cannot open Packages(0) index: Cannot allocate memory(12)
DB: Berkeley DB 5.3.15: (December 19, 2011)
error: cannot open Packages database in /var/lib/rpm
It looks like the configuration is correct based on google searches we’ve done and we only seem to hit this after power-loss. The database does not auto-recover from this state. In response, we need to delete the __db* files and rebuild the rpm database. This takes several minutes. We’d like help understanding what is the real problem and why doesn’t rpm auto-recover in this scenario?

3) Rpm automatically detects and recovers the database. We see the following messages:
Re-opening dbenv with DB_RECOVER ...
BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
BDB1518 Recovery complete at Tue Apr 7 12:29:45 2015
Apr 7 12:29:46 RWGSIPA510385 ApplicationManager[2957]: ERROR: recovery succeeded.
Command eventually completes after about 25 seconds of recovery output. We'd like to understand why rpmdb problems are happening more frequently than in WindRiver 4, but no immediate action is required when rpm auto-recovers.

Steps to Reproduce

1. Run a script that continually executes a "rpm -qi gen4os"
2. Power cycle the board at random times
3. Next time the board boots up and you run the script, one of the following deviations could be observed:
a. Rpm locks up and never returns when the rpm command is issued.
b. rpmdb error: "unable to allocate memory for mutex"
c. rpm auto-recovers the database.
4. If no deviations have been observed, proceed to step #1.

One of the failure can be reproduced after just a couple of power cycles,

Other Downloads

Live chat