I get following from Python2.3.2 with BerkeleyDB 3.3.11
running on linux RH7.3;
------------------------
Traceback (most recent call last):
  File "/raid/ANITA-lite/gse/unpackd.py", line 702, in ?
    PacketObject.shelve()
  File "/raid/ANITA-lite/gse/unpackd.py", line 78, in
shelve
    wvShelf[shelfKey] = self
  File "/usr/local/lib/python2.3/shelve.py", line 130,
in __setitem__
    self.dict[key] = f.getvalue()
  File "/usr/local/lib/python2.3/bsddb/__init__.py",
line 120, in __setitem__
    self.db[key] = value
bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY:
Fatal error, run database recovery -- PANIC: Invalid
argument')
Exception bsddb._db.DBRunRecoveryError: (-30987,
'DB_RUNRECOVERY: Fatal error, run database recovery')
in  ignored
Exception bsddb._db.DBRunRecoveryError: (-30987,
'DB_RUNRECOVERY: Fatal error, run database recovery')
in  ignored
----------------------------------
The server reporting this is running at relatively
heavy load and the error occurs several times per day
(this call occurs roughly 100,000  per day, but only 42
times per any given shelve instance). It  reminds be of
bug report #775414, but this is a non-threaded
application. 
That said, another process is accessing the same
shelve, but I've implemented a lockout system which
should make sure they don't have simultaneous access.
The lockout seems to work fine. 
The same application is running on different machine using 
Python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 and the
same error occured once (to my knowledge), but with
"30987" replaced by "30981" in the traceback above, if
it makes any difference. 
Finally, a third system, python2.3.2 with BerkeleyDB
4.0.14 on linux RH9 (but quite a bit faster, and thus
lighter load) runs w/o reporting this problem so far. 

I don't have a convenient code snipet to exemplify the
problem, but I don't do anything more than open (or
re-open) a shelve and write a single python object
instance to it per opening. If necessary, I can provide
the code in question.