There is a test code named test_env_close in 
bsddb/test, but it
doesn't test the case thoroughly. There seems to be a 
bug in closing
the db environment first -- the lock is not released, and 
sometimes it
seg-faults.

Following is the code that shows this bug.

<code>
import os
from bsddb import db

dir,dbname='test_dbenv','test_db'

def getDbEnv(dir):
    try:
        os.mkdir(dir)
    except:
        pass
    dbenv = db.DBEnv()
    dbenv.open(dir, db.DB_INIT_CDB| db.DB_CREATE 
|db.DB_INIT_MPOOL)
    return dbenv

def getDbHandler(db_env,db_name):
    d = db.DB(dbenv)
    d.open(db_name, db.DB_BTREE, db.DB_CREATE)
    return d

dbenv=getDbEnv(dir)
assert dbenv.lock_stat()['nlocks']==0
d=getDbHandler(dbenv,dbname)
assert dbenv.lock_stat()['nlocks']==1
try:
    dbenv.close()
except db.DBError:
    pass
else:
    assert 0

del d
import gc
gc.collect()
dbenv=getDbEnv(dir)
assert dbenv.lock_stat()['nlocks']==0,'number of current 
locks should
be 0' #this fails
</code>

If you close dbenv before db handler, the lock is not 
released.
Moreover, try this with dbshelve and it segfaults.

<code>
>>> from bsddb import dbshelve
>>> dbenv2=getDbEnv('test_dbenv2')
>>> d2=dbshelve.open(dbname,dbenv=dbenv2)
>>> try:
...     dbenv2.close()
... except db.DBError:
...     pass
... else:
...     assert 0
... 
>>>
>>> 
Exception bsddb._db.DBError: (0, 'DBEnv object has 
been closed') in
Segmentation fault
</code>

Tested on:
 1. linux with Python 2.3 final, Berkeley DB 4.1.25
 2. windows xp with Python 2.3 final (with _bsddb that 
comes along)

Logged In: YES 
user_id=33168

Greg do you know anything about this?  Is it still a problem?

Logged In: YES 
user_id=413

Yes this bug is still there.  A "workaround" is just a
"don't do that" when it comes to closing sleepycat DBEnv
objects while there are things using them still open.  I
believe we can prevent this...

One proposal: internally in _bsddb.c DBEnv could be made to
keep a weak reference to all objects created using it (DB
and DBLock objects) and refuse to call the sleepycat close()
method if any still exist (overridable using a force=1 flag).

Logged In: YES 
user_id=33168

Jane could try the patch in bug 1413192 to see if it fixes
your problem?

Logged In: YES 
user_id=33168

Assuming this was fixed by the patch.