I wrote a program that uses the berkeley-db 4.4.20. In this program, I
creat environment and databases like this:

DB_ENV *dbenv = NULL;
ret = db_env_create(&dbenv, 0);
int mode = 0;
unsigned int flags = DB_CREATE | DB_INIT_LOCK | DB_INIT_MPOOL |
DB_THREAD;
ret = dbenv->open(dbenv, sz_full_dbhome, flags, mode);

ret = db_create(&pdb, pdbenv, 0);
int mode = 0;
unsigned int flags = DB_CREATE | DB_EXCL | DB_THREAD;
ret = pdb->open(pdb, NULL, bdb_file, bdb_name,
(DBTYPE)ptableinfo->StorageType, flags, mode);

Just for test purpose, I terminated the program by pressing keyboard
ctrl+c, or writing some illegal code to cause segment fault, double
free, etc.

Then I found that the environment could be opened successfully, but
some databases can't, error message were:
unable to allocate memory for mutex; resize mutex region

If I restore the __db.001, __db.002, __db.003, __db.004 from backup
which were saved after the environment and databases created, all is
ok.

What's wrong with the envrionment region files? Does the restore work
correctly from then on?

I try to debug into the berkeley-db source code, and find that:

the error message eccurs at mul_alloc.c in function __mutex_alloc_int,
the code is
if (mtxregion->mutex_next == MUTEX_INVALID) {
__db_err(dbenv,
"unable to allocate memory for mutex; resize mutex region");
if (locksys)
MUTEX_SYSTEM_UNLOCK(dbenv);
return (ENOMEM);
}

So I print the mtxregion's info:
$7 = {mutex_offset = 87232,
mutex_size = 100,
thread_off = 0, mtx_region = 2,
mutex_next = 0, stat = {
st_mutex_align = 4,
st_mutex_tas_spins = 1,
st_mutex_cnt = 5352,
st_mutex_free = 0,
st_mutex_inuse = 5352,
st_mutex_inuse_max = 5352,
st_region_wait = 0,
st_region_nowait = 0,
st_regsize = 0}}
It seems that the region's status is not updated because application or
system crash.

Then I restore the environment region files an run to the line
mentioned above, the mtxregion's info is:
$2 = {mutex_offset = 87232,
mutex_size = 100,
thread_off = 0, mtx_region = 2,
mutex_next = 41, stat = {
st_mutex_align = 4,
st_mutex_tas_spins = 1,
st_mutex_cnt = 5352,
st_mutex_free = 3632,
st_mutex_inuse = 1720,
st_mutex_inuse_max = 4097,
st_region_wait = 0,
st_region_nowait = 0,
st_regsize = 0}}

What can i do for these environment region files? Maybe changing the
status manually is a good way to recover


likun.navipal (AT) gmail (DOT) com 写道：

likun.navipal (AT) gmail (DOT) com wrote:
The __db.* files are backing for shared memory that contains various
data structures including mutexes and linked lists. If you interrupt a
program while it's using those data structures, they may be left in
inconsistent states: mutexes may be left locked, linked lists
crosslinked, etc.

The environment files must therefore be removed and recreated whenever
they were not cleanly closed with DBENV->close(). That can be done
using the DBENV->remove() call, manually, or (in environments using
DB_INIT_TXN) using the DB_RECOVER flag to DBENV->open().


At least that time it was. On platforms that don't have a unified
buffer-cache (e.g., HP-UX), copying those files using normal tools may
result in out-of-date data in the copy. Ditto for platforms supporting
mmap(MAP_NOSYNC), such as FreeBSD. Even on other platforms, copying
the files while the program is altering the regions may result in
inconsistent data structures just like a crash would.


For read-only databases, you can get away with removing the __db.*
files on each start up or using the DB_PRIVATE flag to DBENV->open().
If your application needs to be able to survive crashes or failures
while updating databases, then you must use transactions and the
DB_RECOVER flag when restarting whenever the database was not cleanly
closed.


Philip Guenther